bug#59686: 30.0.50; tree-sitter indentation in some loops and conditional statements is wrong

[Yuan Fu <casouri@gmail.com>]

Theodor Thornhill <theo@thornhill.no> writes:

> Bruce Stephens <bruce.stephens@isode.com> writes:
>
>> On 02/12/2022 08:39, Eli Zaretskii wrote:
>>
>>> FWIW, this is an unusual style, so I see no catastrophe if it is not 110%
>>> according to expectations.  Users can easily fix that by tweaking their BOLs
>>> where important.
>>
>>
>> The example I gave would be unusual, I think, but I'd argue that the
>> situations where I saw the problem are quite natural.
>>
>> For example,
>>
>>                  } else if ( MYSTRCMP (attname, SOME_PREFIX_X400ADDRESS) ||
>>                              MYSTRCMP (attname, SOME_PREFIX_X400) ) {
>>                      FOO_ptr orp = foo_std2foo (val);
>>
>> or a function declaration with several arguments with types that are
>> rather long.
>>
>> I agree it's not a critical bug but if there's no appropriate general
>> fix it would be helpful to have some guidance for users to resolve our
>> specific cases.
>
> This is the case I was thinking of.  In the for-loop a grand-parent-bol
> on compound_statement rule would match the 'for' keyword, so the
> indentation will be correct, but this one will not, IIRC.  I plan to dig
> into this some more soon, but motivation left me a little on that issue.
> Maybe we could make a preset like:
>
> ```
> (seq
>  (parent-is "compound_statement") parent (parent-is "for_statement") bol)
> ```
>
>
> In other words, make other presets execute sequentially, move point,
> check again, and if all are true, pick indent offset.  Or allow multiple
> captures, like so:
>
> ```
> (for_statement @offset-anchor
>   body: (compound_statement (_) @to-indent))
> ```
>
> Here the @to-indent capture would get the new indent level based on
> treesit-node-start of for_statement.
>
> What do you think, Yuan?

I think we can just test for the grandparent, there is an
(undocumented) matcher n-p-gp which matches parent and grandparent.

Yuan