bug#61893: 29.0.60; Indentation in c-ts-mode broken again

[Yuan Fu]

> On Mar 2, 2023, at 10:07 PM, Theodor Thornhill <theo@thornhill.no> wrote:
> 
> 
> 
> On 3 March 2023 05:07:44 CET, Yuan Fu <casouri@gmail.com> wrote:
>> 
>> 
>>> On Mar 1, 2023, at 10:31 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>>>> From: Yuan Fu <casouri@gmail.com>
>>>> Date: Wed, 1 Mar 2023 14:08:23 -0800
>>>> Cc: Daniel Martín <mardani29@yahoo.es>,
>>>> Theodor Thornhill <theo@thornhill.no>,
>>>> 61893@debbugs.gnu.org
>>>> 
>>>>> Thanks.  So I wasn't dreaming after all.
>>>> 
>>>> Sorry about that. It should be fixed now.
>>> 
>>> Thanks, it's much better now.
>>> 
>>> I spotted the following problems, not sure if they are new or not: go
>>> to line 297 of dispnew.c, which is "#endif".  Then type "C-e RET" --
>>> point goes to column zero instead of the expected column 6.  This
>>> affects the following 3 lines as well; only the next 'if' fixes the
>>> indentation.  I see the same problem with every "#endif" line.
>>> 
>>> Line 6584 of dispnew.c, which is this:
>>> 
>>> #endif /* HAVE_WINDOW_SYSTEM */
>>> 
>>> exhibits a slightly different incorrect behavior: "C-e RET" on that
>>> line moves point to column 7, not column 6, presumably to align with
>>> the "/*" of the comment?
>>> 
>>> Line 6608 of dispnew.c is just "#else"; typing "C-e RET" there
>>> unexpectedly goes to column 2 instead of 4.
>> 
>> That’s indeed the “align to previous statement”’s fault, caused by preproc 
>> directives Theo was working on. I’ve fixed it. Theo, while working on this, 
>> I found some problem with the current indent for preproc directives. In the 
>> following example:
>> 
>> static void
>> free_glyph_pool (struct glyph_pool *pool)
>> {
>> if (pool)
>>   {
>> #if defined GLYPH_DEBUG
>>     int c = 1;
>> #endif
>>     int check_this = 3;
>> #ifdef stuff
>>     int c = 1;
>> #elif defined stuff
>> int e = 5;
>> #else
>> int d = 11;
>> #endif
>> int check_this = 3;
>>   }
>> }
>> 
>> The elif directive’s and subsequent directives aren’t indented properly. 
>> Looking at the parsed tree, the elif directives are nested in the if 
>> directive, and the nesting can be arbitrarily deep. We probably need a 
>> custom function rather than great-grand-parent to find the anchor, like a 
>> function that keeps going up the tree until the node isn’t a preproc 
>> directive anymore.
>> 
>> Yuan
> 
> Yeah, you're right. I'll see what I can do, but bandwidth is a little low at 
> the moment, so if you have some extra time, don't hesitate to improve it :)

Absolutely, I’ll work on it. 

Yuan