GNU bug report logs - #50640
28.0.50; incorrect highlighting in C++ mode

Previous Next

Package: emacs;

Reported by: Vincent Lefevre <vincent <at> vinc17.net>

Date: Fri, 17 Sep 2021 12:59:02 UTC

Severity: minor

Tags: wontfix

Found in version 28.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Stefan Kangas <stefan <at> marxist.se>, Vincent Lefevre <vincent <at> vinc17.net>
Cc: 50640 <at> debbugs.gnu.org
Subject: bug#50640: 28.0.50; incorrect highlighting in C++ mode
Date: Sat, 25 Sep 2021 21:17:06 +0000
Hello, Vincent and Stefan.

On Sat, Sep 25, 2021 at 11:17:07 -0700, Stefan Kangas wrote:
> Vincent Lefevre <vincent <at> vinc17.net> writes:

> > Consider a test.cc file containing:

> >   if (xMin - xt < t3Font->glyphX ||
> >       yMin - yt < t3Font->glyphY ||
> >       xMax - xt > t3Font->glyphX + t3Font->glyphW ||
> >       yMax - yt > t3Font->glyphY + t3Font->glyphH) {
> >   }

> > (this comes from the xpdf source) and open it with "emacs -Q".

> > The first two "xt" and "yt" are highlighted in green instead of
> > remaining in black.

Yes.  C++ Mode is recognising the < .. < .. > .. > as two nested
templates.  The green is font-lock-type-face.  :-(

> > If I remove the last condition as follows and reopen the file:

> >   if (xMin - xt < t3Font->glyphX ||
> >       yMin - yt < t3Font->glyphY ||
> >       xMax - xt > t3Font->glyphX + t3Font->glyphW) {
> >   }

> > then only the "yt" is highlighted incorrectly.

Yes, then only yt opens a "template", there being no closing > to balance
the xt <.

There's really not much which can be done about this in CC Mode, sorry.
CC Mode's analysis of ambiguous C++ constructs is not very deep, so it
sometimes gets it wrong, as here.

I would be in favour of closing this bug as "won't fix" (actually, can't
fix).

There's an intention in the medium future to introduce rigorous analyses
of source code into Emacs with a language server protocol program called
"Tree Sitter".  That should solve problems like this one.

In the meantime, a workaround would be to change the order of the terms
in that expression so that the <s come after the >s rather than before
them, if you have control of the source code.

> Alan, could you take a look at this bug report?

> (I don't know if you're subscribed to the bug list, my apologies if you
> have already seen it.)

I'm not actually subscribed to the bug list.  I'd have trouble coping
with the volume of posts there.  I try to skim over the archive on the
web every week or so, to try not to miss anything.  So thanks, Stefan,
for the heads up!

-- 
Alan Mackenzie (Nuremberg, Germany).




This bug report was last modified 2 years and 353 days ago.

Previous Next


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