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

Arsen Arsenović via CC-Mode-help <[email protected]> Wed, 18 Sep 2024 18:59:45 +0200
Newsgroups gmane.emacs.cc-mode.general
Message-ID <[email protected]>
--===============4787410865242657032==
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Alan,

Alan Mackenzie <[email protected]> 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.
>=20
>> 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.
=2D-=20
Arsen Arsenovi=C4=87

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZusHAV8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF
MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy
c2VuLm1lAAoJEFLClDAeosSTzfgA/3DSrdkzbFqGwZNMoYM40ryKgBc2K1Uhh///
bjEME4pSAP9s5wmFEr8PGBacHfFg4byxBU8Z9qgkbutw20RUJk8WCw==
=HkaP
-----END PGP SIGNATURE-----
--=-=-=--




--===============4787410865242657032==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============4787410865242657032==--