GNU bug report logs - #3269
23.0.93; C-mode text highlighting

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: emacs-pretest-bug <at> gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
        3269 <at> debbugs.gnu.org,
        Thomas Christensen <thomasc <at> thomaschristensen.org>,
        emacs-devel <at> gnu.org
Subject: bug#3269: 23.0.93; C-mode text highlighting
Date: Mon, 18 May 2009 22:24:02 -0400

>> > OK, here is a patch for half of the problem - it now fontifies a broken
>> > string in a #define properly
>> For some definition of "properly".
> The opening string quote (?\" or ?\') gets f-l-warning-face.  The rest of
> the unclosed string (up to the first EOL which isn't escaped) gets
> f-l-string-face.

> Actually, that's not _quite_ "proper".  A string with an even number of
> backslashes at an EOL is broken at that point, but the font locking
> doesn't show this (yet).  I don't suppose that will bother you all that
> much.  ;-)

I won't oppose the change, but just to be clear: I think that the
increased code complexity introduced by your patch is a worse problem
than the "improper" highlighting it tries to fix.

When code is syntactically incorrect, it's common/normal/expected for
the highlighting to be "incorrect".  This "incorrect" behavior is
actually a good way for the user to notice that his code has problems.
So, from this point of view, there's no need to highlight the opening
string quote with f-l-warning-face: just looking back in the buffer
until you find the first char that is not font-locked as expected will
find the culprit without any need for any extra elisp code, and moreover
this method will work in many more cases.

In other words, messed-up highlighting for incorrect code is just as
good if not better than explicitly recognizing the incorrect code and
highlighting it with f-l-warning-face.

When I introduced the use of f-l-warning-face in C strings, it was not
to avoid messed-up highlighting, but rather to avoid apparently correct
highlighting for code that was actually incorrect/unportable (and even
accepted by GCC at that time).

>> I think this part is more important.  I don't care much (if at all)
>> about how invalid code is highlighted.
> I agree it's important.  I've got it working; what's more, the code
> doesn't advise any of the font lock functions for (>= emacs-major-version
> 22).  I'll commit it tomorrow sometime.

Thanks,


        Stefan

Previous Next

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