GNU bug report logs - #67417
29.1.50; c-ts-mode syntax issues with no brackets

Previous Next

Full log

View this message in rfc822 format

From: Yuan Fu <casouri <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>, Eli Zaretskii <eliz <at> gnu.org>, Arteen Abrishami <arteen <at> linux.ucla.edu>
Cc: 67417 <at> debbugs.gnu.org
Subject: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets
Date: Mon, 27 Nov 2023 22:55:31 -0800

On 11/26/23 6:22 PM, Dmitry Gutov wrote:
> On 27/11/2023 03:47, Yuan Fu wrote:
>> I pushed two commits which should fix the indentation for "break" 
>> after "else", and indentation for empty lines after if/else/for/while 
>> in general. The fix for the general case doesn't use the parse tree, 
>> since the parse tree is often incomplete when you type if (...) and 
>> hit return. Instead it uses a plain regexp match to see if the 
>> previous line starts with if/else/for/while. This seems like a 
>> reasonable heuristic to use before user types more things, at which 
>> point more accurate indentation rules would be used, since the parse 
>> tree should be more complete then.
>
> Sorry, two counter-examples right away:
>
> Type 'elsewhere();' and RET -> the next line is indented 1 level 
> extra, at least until you type some more and then have the line 
> reindented either with pressing TAB or adding semicolon.
>
> Type 'for (;;) {}' and RET -> same.
>
> The first case is easy to guard against (just check that the next char 
> is either space of opening paren), but the second one less so. OTOH, 
> the second case is likely to have a parse tree without errors, so if 
> we also check for that... the heuristic might work.

Well, darn it. And you're right, the second case is a bit hard to 
check... Well I guess for the moment we can remove this heuristic. (I 
tried a bit, and checking for no errors is not so easy.)

Yuan

Previous Next

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