bug#61502: 29.0.60; c-ts-mode auto-indent not working

[Dmitry Gutov]

On 14/02/2023 21:41, Theodor Thornhill via Bug reports for GNU Emacs, 
the Swiss army knife of text editors wrote:
> What do you think?
>
> Theo
>
>
> diff --git a/lisp/treesit.el b/lisp/treesit.el
> index 749781894b..300a703515 100644
> --- a/lisp/treesit.el
> +++ b/lisp/treesit.el
> @@ -1418,6 +1418,8 @@ treesit--indent-1
>            ;; encompass the whitespace.
>            (parent (cond ((and node parser)
>                           (treesit-node-parent node))
> +                       ((equal (treesit-node-type smallest-node) "}")
> +                        (treesit-node-parent smallest-node))
>                          (t (treesit-node-on bol bol)))))
>         (funcall treesit-indent-function node parent bol))))

Here's a counter-example for this patch:

int
main ()
{}|

press RET at |, and you'll see the next line indented by 2 spaces. 
Whereas it shouldn't. This happens, among other things, because the 
added code doesn't distinguish between "real" and "virtual" nodes.

BTW, in this example:

int
main
{
  for (;;)
    {|
}

the "}" node selected by treesit--indent-1 is not "unexisting": it 
selects the closer on the next line, which is parsed to be the part of 
the "for" node. Thanks to its presence, the parent compound_statement 
node contains the point, and everything works out.

And this one

int
main
{
  for (;;)|
}

isn't fixed with your patch because the "unexisting" node in place is a 
different one: "expression_statement", and it has no closers. And it's 
"virtually" placed at the end of the previous line by the parser.

So in most cases if the user has electric-pair-mode on, indentation 
should work okay. Without a pairing solution, though, we see different 
grammars handling incomplete code in different ways for different 
syntactic elements: virtual nodes, container nodes that span after 
point, container nodes that don't span after point, statements that 
parse into a different node type (usually wrapped in ERROR). We could 
report these one by one, hoping for the best. I'm curious how different 
editors fare with indentation in these conditions -- perhaps they use a 
different, more error-proof approach. But it could be that their uses 
are less fussy about indentation than we are.