GNU bug report logs - #73182
CC Mode 5.35.2 (C++//l); 'enum' and 'enum class' appear to not get parsed correctly for indentation

Previous Next

Full log

View this message in rfc822 format

From: Arsen Arsenović <arsen <at> aarsen.me>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 73182 <at> debbugs.gnu.org
Subject: bug#73182: CC Mode 5.35.2 (C++//l); 'enum' and 'enum class' appear to not get parsed correctly for indentation
Date: Wed, 18 Sep 2024 18:59:45 +0200

[Message part 1 (text/plain, inline)]

Hi Alan,

Alan Mackenzie <acm <at> muc.de> writes:

> Hello again, Arsen.
>
>> As a data point here, the correct indentation is present all over GCC
>> (which has people using everything from vi over notepad++ to VScode, and
>> naturally, Emacs), but it is mixed up, presumably partially as a result
>> of this bug, so I'd prefer if the editor would DTRT OOTB.
>
> Thanks.  I've just written a little AWK script to count occurrences of
> the "standard" indentation (the opening brace directly under enum in
> column 0) and "non-standard" indentation (the opening brace indented
> under enum in column 0).  The results have surprised me somewhat.

Ah!  Great idea.  Thanks for collecting empirical data.  :-)

> In "my" version of gcc-13.3.1, there are 947 standard indentations and
> 81 non-standard.  Even in the Emacs sources (.c, .h, .m, and .cc) we
> have 79 standard to 149 non-standard.  That's ~35% of enums looking
> like they've been indented by private CC Mode styles, or by hand.

Huh, that's interesting.  I expected more skew towards current
behaviour.

> So my reservations from ten years ago about possible chaos were
> misplaced; this chaos has already happened.
>
> As an additional factor, the newish modes, c-ts-mode, c++-ts-mode,
> etc., indent in the standard fashion.  Also, these modes are hardly
> the cause of the standard indentation in the Emacs sources, many of
> which date back many years.
>
> So it now seems clear that the decision not to fix the bug in 2014 was
> a mistake.  I agree with you, it should be fixed now.
> 
>> Also, if there is intention to use automatic code formatting tools,
>> which some have expressed as desirable for the toolchain projects (and I
>> don't disagree - helps people who aren't using Emacs to get indent right
>> easily ;-) ), having incorrect indentation by the editor will be
>> burdensome, as it'd result in the editor and formatter fighting often.
>
>> And, given that nobody (AFAIK) uses Emacs to mass-reindent code, I
>> suspect the fallout of a fix will be gradual and silent.
>
>> As an alternative to fixing this bug so that the token is recognized as
>> a struct, we could have a new token for enum that does get indented
>> correctly OOTB and that affected projects adjust to avoid trouble in
>> their codebases.
>
> That is one possibility, yes.  It seems clear that parsing enum
> constructs as brace-lists is suboptimal, but I feel that parsing them as
> structs, although easy, would be taking things just too far.  So I think
> new symbols enum-open, etc., are the best way to go, even though this is
> quite a lot of work (e.g. amending the CC Mode manual, the test suite,
> ....).
>
> So, I will fix this bug.

Thank you again!

Have a lovely day.
-- 
Arsen Arsenović

[signature.asc (application/pgp-signature, inline)]

Previous Next

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