Utility function to handle empty query results and templates

[Maarrk]

More general implementation of #1359

This also documents current workaround for #1343

[zefhemel]

Hmm. Need to think if the bug isn't really the incompatibility with Lua here. Not sure if we should double down on this being useful.

I'd rather make this lua constituent otherwise we're just asking for future trouble.

[wbhouston]

I think this will be a nice change! I added some minor comments.

[wbhouston]

I think the lead in here should be more inclusive of the following headers. Maybe:

Here are some of the expected differences and planned and not planned features:

[wbhouston]

Typo on nad in the docs quote.

[wbhouston]

I added a section to [[API/string]] about how Lua patterns and Space Lua patterns have some key differences, not just for gmatch. What do you think about removing:

(some patterns in gmatch don’t work correctly)

and adding a bullet to the Differences section above, maybe:

• lua patterns are translated to Javascript regex, so there are some [[API/string|key differences]].

[Maarrk]

Probably same comment applies as the empty table truthiness. See link in #1284, maybe we can actually get 100% compatibility?

[Maarrk]

Hmm. Need to think if the bug isn't really the incompatibility with Lua here. Not sure if we should double down on this being useful.

I'd rather make this lua constituent otherwise we're just asking for future trouble.

Essentially we would like to have some behavior like ?? operator. A Lua-compatible solution would be to add a function that checks for truthiness in a different way, appropriate for content:

```space-lua
function some(value)
  if type(value) == "table" then
    -- if next(value) == nil then return nil end
    -- The above is supposed to work, but let's use pairs in this example:
    for k, v in pairs(value) do
      return value
    end
    return nil
  end
  if value == "" then return nil end
  return value
end
```

${some(1) or "*no result*"}
${some(0) or "*no result*"}
${some("text") or "*no result*"}
${some("") or "*no result*"}
${some({}) or "*no result*"}
${some({1, 2}) or "*no result*"}
${some({[2]=1})}
${some({foo="bar"}) or "*no result*"}

I'll keep in mind that we're aiming for full Lua compatibility. Then a fully Lua-compatible way would be ${some(query[[ ... ]]) or "No results"}. I'd say to suggest this use in the documentation, this should be always available. I'm happy to add something like this to standard library, but I'd like a comment from @zefhemel on the name. I went with some(), because this pattern reminded me of Some in Rust, and its unwrap_or method. But there ought to be some monadic wisdom to name it better 😝

---

Yet another conformant solution could be to use metatables to override an operation on the query result. By setting our custom method for __bxor we'd have syntax like:

${query[[ ... ]] ~ "no results"}

I don't have a strong opinion on which operator to use, I went with XOR because "only one of the inputs is true"

This would be completely normal Lua, and even shorter syntax than now (by 1 character xD). I'm not worried about making query function inconsistent with expectations, since it already has special parsing rules, but it may confuse new users as to what ~ operator does. On the other hand, maybe them knowing about metatables is helpful for their own scripts?

Bonus: Maybe this would be a path for composing queries together using some other overridable operators? Like ${query[[ ]] .. query[[ ]]} to make them into a single table with columns and rows from both...

[zefhemel]

I like the some name and approach. I wouldn't do weird metatable operator hacks (for now). I think being as Lua-y as reasonable is a good way to bring people in and to also allow them to use gained skills in other Lua environments.

[Maarrk]

The scope has changed a bit, but I thought that it's better to just reorganize this PR to keep the discussion about possible options.

I think this is a more elegant solution, are we OK to remove #1359? Everyone is supposed to know this is unstable version, and I don't recall any changelog or forum talk about that feature.

[zefhemel]

Very nice. I like this solution. And indeed I hope/assume people will not have used the extra template.each argument yet, and if so they'll figure it out 😄