GNU bug report logs - #56848
CC Mode fontification bug

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56848 in the body.
You can then email your comments to 56848 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: bug-gnu-emacs <at> gnu.org
Subject: CC Mode fontification bug
Date: Sun, 31 Jul 2022 00:16:37 +0000

[Message part 1 (text/plain, inline)]

Recipe:

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

This is a BUG.

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.

Patch attached.

With the patch, scrolling again through an already fontified buffer is 
~25% faster.

[Be-conservative-with-occurrences-of-newly-found-types.patch (text/x-diff, attachment)]

Message #8 received at 56848 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56848 <at> debbugs.gnu.org
Subject: Re: 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.

Message #11 received at 56848 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56848 <at> debbugs.gnu.org
Subject: Re: bug#56848: CC Mode fontification bug
Date: Sun, 31 Jul 2022 08:08:45 +0000

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

Message #16 received at 56848-done <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: 56848-done <at> debbugs.gnu.org
Cc: Alan Mackenzie <acm <at> muc.de>
Subject: Re: bug#56848: CC Mode fontification bug
Date: Sat, 14 Jan 2023 21:28:24 +0000

Closing this bug.  The proposed patch has been included in commits 
4bd8ad2bc5 and 1cbc22b9c7.

Message #23 received at 56848-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56848-done <at> debbugs.gnu.org, control <at> debbugs.gnu.org
Subject: Re: bug#56848: CC Mode fontification bug
Date: Sun, 15 Jan 2023 12:32:31 +0000

reopen 56848
quit

Hello, Gregory.

Thanks for the Cc:!

I'm (trying to) reopen the bug with this post.

On Sat, Jan 14, 2023 at 21:28:24 +0000, Gregory Heytings wrote:

> Closing this bug.  The proposed patch has been included in commits 
> 4bd8ad2bc5 and 1cbc22b9c7.

I wasn't previously aware of this bug.  I'm not at all happy about the
patches you proposed and have applied.  In particular, you say
(2022-07-31):

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

, without justification.  There are circumstances in which identifiers
with font-lock-type-face need to be refontified with
font-lock-variable-face, and the reverse, amongs others.  It was trying
to optimise in this area which caused some of Po Lu's bug reports over
the last three months.

An example of what can go wrong is, supposing we have just mistyped

    food sausage;

as

    foo sausage;

..  "All" the identifiers "foo" throughout the buffer will get fontified
with type-face.  On returning to the line and correcting "foo" to
"food", these "foo"s need to be refontified.  This actual scenario
occurred in one of Po's bug reports.

I think that after the patches in this bug, the refontification won't
happen.  I've reopened the bug, and I'm asking you to reconsider these
things.

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #26 received at 56848 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 56848 <at> debbugs.gnu.org
Subject: Re: bug#56848: CC Mode fontification bug
Date: Sun, 15 Jan 2023 12:52:59 +0000

Hi Alan,

>> Closing this bug.  The proposed patch has been included in commits 
>> 4bd8ad2bc5 and 1cbc22b9c7.
>
> I wasn't previously aware of this bug.  I'm not at all happy about the 
> patches you proposed and have applied.
>

My post was apparently not clear enough, sorry for that: I did not apply 
anything, I closed this bug and recorded in the bug tracker that it was 
fixed by two of your commits.  The current state of the function that the 
patch modified is essentially what was proposed in the patch.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.