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

[Theodor Thornhill]

On 15 February 2023 00:57:17 CET, Dmitry Gutov <dgutov@yandex.ru> wrote:
>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.

Sure, i agree - the patch was not a change request, merely an example to show 
why the root node was chosen rather than the closer compound_statement node.