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

Previous Next

Package: emacs;

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

Date: Thu, 21 Jul 2022 18:01:01 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

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: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 26 Jul 2022 15:12:24 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  56682 <at> debbugs.gnu.org,
>   monnier <at> iro.umontreal.ca
> Date: Tue, 26 Jul 2022 08:51:54 +0200
> 
> Gregory Heytings <gregory <at> heytings.org> writes:
> 
> > 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.
> 
> That's kind of funny :-):
> 
> (setq isearch-lazy-highlight nil)

Did you try this on master or on the feature branch?

And I found that customizing lazy-highlight-max-at-a-time and
lazy-highlight-interval can alleviate the problem to some extent.

The reason seems to be that lazy-highlighting tries to highlight every
match "in th window", but its interpretation of "in the window" seems
to be "buffer position before window-end position".  Which of course
includes a lot of stuff in a window with truncate-lines.
This bug report was last modified 2 years and 8 days ago.

Previous Next

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