GNU bug report logs - #58578
29.0.50; Font lock randomly breaks in some buffers and gets worse over time

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 58578 in the body.
You can then email your comments to 58578 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: Stefan Kangas <stefankangas <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Font lock randomly breaks in some buffers and gets worse
 over time
Date: Mon, 17 Oct 2022 04:40:50 +0000

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

I'm seeing broken font lock in long running sessions, seemingly at
random.  After it goes on for a while, font lock breaks down completely
in some buffers, and it seemingly gets worse over time.  In some cases,
the only remedy has been to restart Emacs.

This has been going on for a couple of weeks at least, and I thought I
was doing something wrong, so I haven't reported it.  I also haven't
seriously tried to reproduce it in "emacs -Q", so I've only seen using
my own init file.  (I haven't made any changes in that configuration
recently that would obviously relate to font-locking.)

I've failed at my attempts to understand it, so I hope that someone can
help me with ideas on how to debug this.  What makes this a bit
discouraging to debug is that it usually only shows up after more than a
day of use (sometimes several days, AFAIR), and it's unbearable to work
in "emacs -Q" for that long.  I also have no idea where to even begin
looking.

I have seen it in more than one major mode, both built-in and
third-party modes (from the top of my head, I've seen it in `c-mode' and
`org-mode' too).

Here is a screenshot from `notmuch-message-mode', based on
`message-mode':

[Message part 2 (text/plain, attachment)]

[font-lock-bug.png (image/png, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 58578 <at> debbugs.gnu.org
Subject: Re: bug#58578: 29.0.50;
 Font lock randomly breaks in some buffers and gets worse over time
Date: Mon, 17 Oct 2022 09:42:57 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 17 Oct 2022 04:40:50 +0000
> 
> I'm seeing broken font lock in long running sessions, seemingly at
> random.  After it goes on for a while, font lock breaks down completely
> in some buffers, and it seemingly gets worse over time.  In some cases,
> the only remedy has been to restart Emacs.
> 
> This has been going on for a couple of weeks at least, and I thought I
> was doing something wrong, so I haven't reported it.  I also haven't
> seriously tried to reproduce it in "emacs -Q", so I've only seen using
> my own init file.  (I haven't made any changes in that configuration
> recently that would obviously relate to font-locking.)
> 
> I've failed at my attempts to understand it, so I hope that someone can
> help me with ideas on how to debug this.  What makes this a bit
> discouraging to debug is that it usually only shows up after more than a
> day of use (sometimes several days, AFAIR), and it's unbearable to work
> in "emacs -Q" for that long.  I also have no idea where to even begin
> looking.
> 
> I have seen it in more than one major mode, both built-in and
> third-party modes (from the top of my head, I've seen it in `c-mode' and
> `org-mode' too).

Some questions/ideas for you:

What happens if you toggle font-lock-mode off and on again in the
affected buffers?  For CC Mode and Org Mode, what happens if you kill
the buffer and revisit the file?

Is it possible that long-line-optimizations-p returns non-nil in the
affected buffers?

Do you see any relevant messages in *Messages* when this happens?

Did you make _any_ changes in your init files lately?  If so, I
suggest to undo them one by one to see if any of them are responsible.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: 58578 <at> debbugs.gnu.org
Subject: Re: bug#58578: 29.0.50; Font lock randomly breaks in some buffers and
 gets worse over time
Date: Mon, 17 Oct 2022 07:27:56 +0000

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Here is a screenshot from `notmuch-message-mode', based on
> `message-mode':

For a while, I could reproduce the incorrect fontification in a
`notmuch-message-mode' buffer after replying to an email.

Everything looks fine when I first create the buffer.  But when I move
point to the end of some quoted line, and press RET (`newline'), there
is incorrect fontification on the new line, and I see:

     There are text properties here:
       face                 message-cited-text-1
       fontified            t

(It looks like in the screenshot in the last email.)

If I go to the beginning of another line and press C-o (`open-line'), the
fontification is correct, and there is no face property on the new line:

     There are text properties here:
       fontified            t

Why would `newline' and `open-line' lead to different results?
It seems very strange to me.

[time passes]

What is even stranger is that now, an hour or two later, I can no longer
reproduce this behavior, not in the same session and not even in the same
buffers as before.  The incorrect fontification only still remains on the same
lines as before, however.

I did no particular changes that should affect this.  I was just sending emails
and doing some unrelated ELisp coding.

Should I start looking at my timers here, or something?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 58578 <at> debbugs.gnu.org
Subject: Re: bug#58578: 29.0.50;
 Font lock randomly breaks in some buffers and gets worse over time
Date: Mon, 17 Oct 2022 11:20:01 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 17 Oct 2022 07:27:56 +0000
> 
> Stefan Kangas <stefankangas <at> gmail.com> writes:
> 
> > Here is a screenshot from `notmuch-message-mode', based on
> > `message-mode':
> 
> For a while, I could reproduce the incorrect fontification in a
> `notmuch-message-mode' buffer after replying to an email.
> 
> Everything looks fine when I first create the buffer.  But when I move
> point to the end of some quoted line, and press RET (`newline'), there
> is incorrect fontification on the new line, and I see:
> 
>      There are text properties here:
>        face                 message-cited-text-1
>        fontified            t
> 
> (It looks like in the screenshot in the last email.)
> 
> If I go to the beginning of another line and press C-o (`open-line'), the
> fontification is correct, and there is no face property on the new line:
> 
>      There are text properties here:
>        fontified            t
> 
> Why would `newline' and `open-line' lead to different results?
> It seems very strange to me.
> 
> [time passes]
> 
> What is even stranger is that now, an hour or two later, I can no longer
> reproduce this behavior, not in the same session and not even in the same
> buffers as before.  The incorrect fontification only still remains on the same
> lines as before, however.
> 
> I did no particular changes that should affect this.  I was just sending emails
> and doing some unrelated ELisp coding.
> 
> Should I start looking at my timers here, or something?

Maybe.  Or maybe this is specific to notmuch-message-mode.

I would suggest to focus on more popular modes.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58578-done <at> debbugs.gnu.org
Subject: Re: bug#58578: 29.0.50; Font lock randomly breaks in some buffers and
 gets worse over time
Date: Sun, 10 Sep 2023 16:53:11 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

> Maybe.  Or maybe this is specific to notmuch-message-mode.
>
> I would suggest to focus on more popular modes.

This heisenbug has not manifested itself in a while, so I'm closing this
bug.  I will reopen if it pops up again.

Previous Next

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