This kind of broken command does not have a position information, and
was producing a panic message in the server because it makes the
reasonable assumption that every command returned by `parserCommand`
has a position.
We should never assume a `Syntax` node has a specific number of
children because the parser error recovery may produce partial
abstract syntax trees. We should use `stx[i]` instead because
`Syntax.getOp` returns `Syntax.missing` when `i` is out of bounds.
I am hitting many error recovery problems. This is an attempt to make
auto-completion more robust.
For example, we currently can't auto complete inside of parentheses.
The syntax tree for the syntactically incorrect tern `(s. , 0)` is
```
(Term.paren "(" [(Term.proj `s ".")])
```
The elaborator for `paren` fails to match this partial syntax tree and
returns an error. I considered adding code to the `else` branch of
this elaborator and handle partial trees there. However, we would
still be losing information for the other elements of the tuple.
Example: no hover information for them.
The helper parser makes sure we don't lose information.
It didn't help with the problem I was having, but we talked about
customizing this behavior in the past. So, I will leave the function
here because it is convenient for trying experiments without having to
modify `Quotation.lean` and `update-stage0`
After a parser error in a command, we are "swallowing" all command
parsing errors until a command was succesfully parsed.
This was producing counterintuitive behavior in the IDEs.
We currently allow spaces between `.` and the "field" name, and this
was creating problems when auto-completing at `f (y.| a b)`
where `|` represents the cursor position
The `InfoTree` had a node for `y. a` and its tail position is after
the cursor position.
For many data structures having an ordering is necessary. This one adds the `Ord` type class and a deriving handler for it. The ordering is based on order of constructors followed by lexicographical ordering within a constructor.
