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

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, Gregory Heytings <gregory <at> heytings.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 26 Jul 2022 14:22:25 +0200

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

This is on Gregory's branch.

On Tue, 26 Jul 2022, 14:12 Eli Zaretskii, <eliz <at> gnu.org> wrote:

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

[Message part 2 (text/html, inline)]

Previous Next

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