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

Previous Next

Package: emacs;

Reported by: Arteen Abrishami <arteen <at> linux.ucla.edu>

Date: Thu, 23 Nov 2023 22:00:03 UTC

Severity: normal

Found in version 29.1.50

Fixed in version 29.2

Done: Dmitry Gutov <dmitry <at> gutov.dev>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 67417 <at> debbugs.gnu.org, dmitry <at> gutov.dev, arteen <at> linux.ucla.edu
Subject: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets
Date: Tue, 28 Nov 2023 16:27:37 +0200
> Date: Mon, 27 Nov 2023 22:55:31 -0800
> Cc: 67417 <at> debbugs.gnu.org
> From: Yuan Fu <casouri <at> gmail.com>
> 
> 
> 
> 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.)

Does this mean you need to revert something on the emacs-29 branch?




This bug report was last modified 1 year and 163 days ago.

Previous Next


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