GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 26 Jul 2022 15:09:38 +0300

> Date: Tue, 26 Jul 2022 11:53:28 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> 
> 
> >> Hmmm...  After 350e97d78e, Isearch locks Emacs with 
> >> toggle-truncate-lines. Recipe:
> >>
> >> C-x C-f long-line.xml
> >> C-x x t
> >> C-s </
> >>
> >> You have to kill Emacs, C-g does not work.
> >
> > I see the same on master, where that change is not yet installed.
> 
> Are you sure?  I don't see the same at 304e2a3a05.  C-s is slow, but it 
> does not hang Emacs, and the effect of C-s </ is visible within a couple 
> of seconds.

I don't know the difference between "slow" and "hang".  Gerd says it
eventually finishes, so it isn't a "hang" at least on his machine.
And my build is unoptimized, so what is "slow" for you probably
qualifies as "hang" for me.

If you disable lazy-highlighting, does the problem go away?

And if you customize lazy-highlight-interval and
lazy-highlight-max-at-a-time to reasonable values, doesn't the "hang"
becomes much shorter?

Previous Next

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