GNU bug report logs - #56848
CC Mode fontification bug

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Sun, 31 Jul 2022 00:17:01 UTC

Severity: normal

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56848 <at> debbugs.gnu.org
Subject: bug#56848: CC Mode fontification bug
Date: Sun, 31 Jul 2022 08:47:29 +0300
> Date: Sun, 31 Jul 2022 00:16:37 +0000
> From: Gregory Heytings <gregory <at> 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.




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.