emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#3269: 23.0.93; C-mode text highlighting


From: Stefan Monnier
Subject: Re: bug#3269: 23.0.93; C-mode text highlighting
Date: Mon, 18 May 2009 22:24:02 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]