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

[Theodor Thornhill]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: 61502@debbugs.gnu.org
>> Date: Tue, 14 Feb 2023 20:41:04 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Keep typing whatever code you wan "int main" to include, and it will
>> > auto-indent soon enough.
>> 
>> Yeah, but.
>
> My point is that what we are used to from CC mode does not necessarily
> have to work the same way with tree-sitter based modes.  As long as
> the indentation fixes itself soon enough, we are still fine, I think.
>
>> int
>> main
>> {
>>   for (;;)
>>     {|
>> }
>> ```
>> 
>> If you press RET if point at | you'll see we indent immediately, even
>> though there is no closing bracket.  This is because of how
>> treesit-indent defaults to treesit-node-on when there is no node at
>> point.  So in the example without the for loop the parent is then set to
>> whatever treesit-node-on returns, which in this case is the root
>> node. That means that the rule for translation_unit is selected, which
>> is:
>> 
>>          `(((parent-is "translation_unit") point-min 0)
>> 
>> However, what's interesting here is that treesit-indent selects an
>> "unexisting" node as the "smallest-node".  Specifically that is:
>> 
>>          #<treesit-node "}" in 13-13>
>> 
>> This node in turn will return "compound_statement" if you look for its
>> parent.  It seems some parsers detects these nodes, so maybe we should
>> add some handling for that?  Some "block-closers" code in
>> treesit-node-on, so that treesit-node-on doesn't default to the root
>> node, but rather the compound_statement?
>
> AFAIU, you are talking about hitting RET in the following situation
> (where "|" stands for point):
>
> int main ()
> {|
> }
>
> However, the OP presented a slightly different situation:
>
> int main ()
> {|
>
> That is, without the closing brace.  In that case, there's no "}" in
> the source.  Are you saying that the tree-sitter's parser "invents"
> such a node?

That's correct. In tree-sitter-c at least that's the case.

>
> And why does treesit-indent select that "unexisting" node in the first
> place?
>

This code:

         (smallest-node
          (cond ((null (treesit-parser-list)) nil)
                ((eq 1 (length (treesit-parser-list)))
                 (treesit-node-at bol))
                ((treesit-language-at (point))
                 (treesit-node-at bol (treesit-language-at (point))))
                (t (treesit-node-at bol))))

treesit-node-at selects the "invented" node.

>> I'm not sure this explanation was easy to follow at all, but I'll add a
>> hack in a diff to make the point hopefully a little clearer.
>> 
>> What do you think?
>
> How well did you test that?

Not well at all.  I just created that hack to make the example a little
clearer.  I think the change probably should go into treesit-node-on.

> Does it fix similar problems with struct
> definition at top-level?  Are there any regressions elsewhere in the
> indentation?

Not that I found, but I'll experiment some more.

>
> There are also other similar cases, but with code on deeper levels.
> Try this, for example (where "|" again stands for point):
>
> int
> main
> {
>   for (;;)|
> }
>
> Now press RET and observe the result:
>
> int
> main
> {
>   for (;;)
>   |
> }
>
> instead of the expected
>
> int
> main
> {
>   for (;;)
>     |
> }
>
> Why?

If I'm not mistaken the same "problem". Treesit-node-on selects the
surrounding compound_statement, so it only indents one step from column 0.

>
> (Of course, as soon as you type ";", the code is automatically
> reindented to yield the correct indentation.  Which was my point.)

Yeah, but consider the same example of yours without the closing brace:

```
int
main
{
  for (;;)|
```

Now type RET

```
int
main
{
  for (;;)
|
```

Now type {

```
int
main
{
  for (;;)
    {|
```

Now type RET

```
int
main
{
  for (;;)
    {
|
```

Which is what I consider a little confusing.  We get different
indentation with and without the closed scope.

Theo