GNU bug report logs - #64204
C/C++ local variables not syntax highlighted if they start with $

Previous Next

Package: emacs;

Reported by: Joseph Garvin <k04jg02 <at> gmail.com>

Date: Wed, 21 Jun 2023 11:28:02 UTC

Severity: normal

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

Bug is archived. No further changes may be made.

Full log


Message #50 received at 64204 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 64204 <at> debbugs.gnu.org
Subject: Re: bug#64204: C/C++ local variables not syntax highlighted if they
 start with $
Date: Thu, 22 Jun 2023 12:33:13 +0000
Hello, 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 <at> yahoo.com, 64204 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> 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.

Having thought about this some more, maybe it's not such a big problem.
The strategy I'm thinking about would not attempt to analyse identifiers
with $ in them.  Instead, it would amend only the fontification, with a
new ad-hoc entry in font-lock-keywords which would go over all
identifiers at the end of the fontification, and splat those containing a
$ with font-lock-warning-face.

I can see more problems arising when people start wanting to use
identifiers with random Unicode characters in them.  :-(

-- 
Alan Mackenzie (Nuremberg, Germany).




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

Previous Next


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