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

[Theodor Thornhill]

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 :)

Theo