[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#3269: 23.0.93; C-mode text highlighting
From: |
Stefan Monnier |
Subject: |
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
- bug#3269: 23.0.93; C-mode text highlighting, Thomas Christensen, 2009/05/14
- bug#3269: 23.0.93; C-mode text highlighting, Andreas Schwab, 2009/05/14
- bug#3269: 23.0.93; C-mode text highlighting, Alan Mackenzie, 2009/05/14
- bug#3269: 23.0.93; C-mode text highlighting, Alan Mackenzie, 2009/05/18
- bug#3269: 23.0.93; C-mode text highlighting, Stefan Monnier, 2009/05/18
- bug#3269: 23.0.93; C-mode text highlighting, Alan Mackenzie, 2009/05/18
- bug#3269: 23.0.93; C-mode text highlighting,
Stefan Monnier <=
- bug#3269: 23.0.93; C-mode text highlighting, Alan Mackenzie, 2009/05/19
- bug#3269: 23.0.93; C-mode text highlighting, Stefan Monnier, 2009/05/19
- bug#3269: 23.0.93; C-mode text highlighting, Alan Mackenzie, 2009/05/19