GNU bug report logs -
#56848
CC Mode fontification bug
Previous Next
Full log
Message #11 received at 56848 <at> debbugs.gnu.org (full text, mbox):
>
> As an aside, one should be very careful with trusting the likes of
>
> M-: (get-char-property 28 'fontified) RET
>
> because entering the minibuffer triggers a rather thorough redisplay
> cycle, which could change the 'fontified' property one is trying to
> obtain. Instead, it is advisable to write a simple command that would
> do the evaluation, then bind it to a single key, like F5, and invoke
> through that key. Even better, invoke the function from the debugger.
>
> (I'm not saying that the nil above is inaccurate, since the problematic
> position is outside the window, I'm just saying one should be very
> careful with this stuff.)
>
Indeed, I tried to make the recipe as simple as possible, but during my
tests I did use such a function.
>
> The fact that the word 'window' is involved in both cases seems to ring
> a bell: isn't there a feature in CC Mode's fontifications whereby it
> does something with identifiers whose type it knows about, by going
> forward and back into the buffer and "fixing" their fontifications?
>
Yes, that's what the 'c-fontify-new-found-type' modified by the patch
does. Currently, when a new type has been found, all occurrences of its
identifier are "unfontified" with:
(widen)
(goto-char (point-min))
(while (re-search-forward ...) (put-text-property ... 'fontified nil))
When font locking has already put, say, a font-lock-comment-face, or a
font-lock-function-name-face, or a font-lock-variable-name-face on an
occurrence of that identifier, there is no reason to undo that. It is
only occurrences that have been marked as "fontified" but on which no face
has been put that should be unfontified.
This bug report was last modified 2 years and 123 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.