|
From: | GNU bug Tracking System |
Subject: | bug#64204: closed (C/C++ local variables not syntax highlighted if they start with $) |
Date: | Wed, 28 Jun 2023 18:46:02 +0000 |
Your message dated Wed, 28 Jun 2023 18:45:09 +0000 with message-id <ZJx_tZu8KmhZvbWG@ACM> and subject line Re: bug#64204: C/C++ local variables not syntax highlighted if they start with $ has caused the debbugs.gnu.org bug report #64204, regarding C/C++ local variables not syntax highlighted if they start with $ to be marked as done. (If you believe you have received this mail in error, please contact help-debbugs@gnu.org.) -- 64204: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64204 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems
--- Begin Message ---Subject: C/C++ local variables not syntax highlighted if they start with $ Date: Tue, 20 Jun 2023 15:54:52 -0500 Start emacs with `emacs -Q`, press C-x C-f and type in a filename that
ends in .cpp like "foo.cpp". Then type in:
int main()
{
int a = 0;
int b = 0;
int $ = 0;
int d$ = 0;
int $e = 0;
}
Yes it compiles! GCC, Clang, and MSVC all have a non-standardextension that allows $ signs to appear in C/C++ variable and typenames: https://gcc.gnu.org/onlinedocs/gcc/Dollar-Signs.html
Then a,b,d$ will be highlighted correctly as local vars, but not $ or
$e. The highlighting doesn't appear to work whenever $ is the first or
only character. Since emacs is accepting of the $ sign anywhere else in
the variable name, I suspect supporting $ was intended, even though it's
non-standard. Even if not intended, it's a popular syntax
extension supported by the major current compilers and whose history
goes back to the DEC compiler, so support would be nice.
In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
of 2021-05-14 built on eruv
Repository revision: efc24f1e0bb127481bcc9c3054c57c4cd3c99aa9
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Ubuntu 20.04.6 LTS
--- End Message ---
--- Begin Message ---Subject: Re: bug#64204: C/C++ local variables not syntax highlighted if they start with $ Date: Wed, 28 Jun 2023 18:45:09 +0000 Hello, Joseph and Eli. On Thu, Jun 22, 2023 at 13:13:59 +0300, Eli Zaretskii wrote: > > Date: Thu, 22 Jun 2023 09:11:38 +0000 > > Cc: luangruo@yahoo.com, 64204@debbugs.gnu.org > > From: Alan Mackenzie <acm@muc.de> > > > Thanks, but shouldn't this be optional behavior, which users should be > > > able to control? Standard C disallows '$' in identifiers AFAIK, and > > > some users might wish to follow the Standard. > > The thing is, such an option would be difficult to implement. At the > > moment, c-symbol-start and c-symbol-key (regular expressions which match > > the start of an identifier and all of one) are calculated in cc-langs.el > > at compilation time. They are widely used (~40 times) in the indentation > > engine and fontification. > > It would be necessary to change these constants to variables, probably > > doubling the number of relevant c-lang-const's in cc-langs.el, and to add > > a mechanism to toggle between them at run time. > > I don't feel that the benefit from this new option would really be worth > > the work it would take to implement. > I do feel it's worth the effort. If we value correct fontification, > of course. I don't know what my opinions on this mean for you, but > there you have it. I cannot force you make this change, of course, I > can only try to convince. :-) OK, the fontification of identifiers with $ is now working. By default they are fontified as normal identifiers (i.e. with font-lock-type-face, font-lock-variable-name-face, or font-lock-function-name-face), but if the (new) customisable option c-warn-ids-with-dollar is set to non-nil, font-lock-warning-face is used instead. The above applies only to C, C++, and Objective C Modes, and to any derived modes which enable the mechanism. So, I'm closing the bug now with this post. -- Alan Mackenzie (Nuremberg, Germany).
--- End Message ---
[Prev in Thread] | Current Thread | [Next in Thread] |