bug#56848: CC Mode fontification bug

[Eli Zaretskii]

> Date: Sun, 31 Jul 2022 00:16:37 +0000
> From: Gregory Heytings <gregory@heytings.org>
> 
> emacs -Q
> C-x C-f src/xdisp.c RET
> M-g c 28 RET
> ;; take note of the word there: "window"
> M-: (get-char-property 28 'fontified) RET
> ;; observe that this returns t
> M-g g 800 RET
> C-v
> M-: (get-char-property 28 'fontified) RET
> ;; observe that this returns nil, because "struct window" is now visible

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

FWIW, I can reproduce this on master, but not on the release branch.
I thought this was related to bug#56841, but since that one happens on
emacs-28 as well, it probably is a separate issue.

> When font locking has put a fontified property and one of the 
> font-lock-*-faces on characters in the buffer, a mode should not undo that 
> unless it has a very good reason to do so.  Otherwise scrolling again 
> through an already fontified buffer calls fontification functions again 
> without reason.

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?

Thanks.