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==--