GNU bug report logs - #60496
29.0.60; c-ts-mode: Broken indentation with linux style conditionals

Previous Next

Full log

View this message in rfc822 format

From: Yuan Fu <casouri <at> gmail.com>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: bruce.stephens <at> isode.com, eliz <at> gnu.org, 60496 <at> debbugs.gnu.org, 59686 <at> debbugs.gnu.org
Subject: bug#60496: 29.0.60; c-ts-mode: Broken indentation with linux  style conditionals
Date: Sun, 15 Jan 2023 01:23:45 -0800

Yuan Fu <casouri <at> gmail.com> writes:

>> On Dec 3, 2022, at 3:08 AM, Theodor Thornhill <theo <at> thornhill.no> wrote:
>> 
>> 
>> 
>> On 3 December 2022 11:48:34 CET, Yuan Fu <casouri <at> gmail.com> wrote:
>>> 
>>> Theodor Thornhill <theo <at> thornhill.no> writes:
>>> 
>>>> Bruce Stephens <bruce.stephens <at> 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
>> 
>> Yeah I know, but that doesn't work in every case we see this behavior.
>
> I see, but at least it fixes common cases that I can think of right now, namely if, for, while. What are some other cases?

I just pushed a change (189d976dbae) that I think fixes this kind of
problems. Instead of trying to figure out the right anchor, we simply
count the number of {} blocks between the node at point and the root
node, and use that number (multiplied by c-ts-mode-indent-offset) as the
indentation.

If you think about it, both

for (a;b;c)
{
  |
}

and

for (a;
     b;
     c)
{
  |     
}

are one block-level deep.  So multi-line conditions is not an issue
anymore.

And

int main()
{
  if ()
    {
      |
    }
}

is 2 block-level deep, etc.

Yuan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.