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: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, dgutov <at> yandex.ru
Subject: bug#56682: locked narrowing
Date: Fri, 02 Dec 2022 10:04:37 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 56682 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>,  dgutov <at> yandex.ru
> Date: Thu, 01 Dec 2022 21:52:03 -0500
> 
> My suggestion was to have as "steady state" that "everything is scanned
> except for a region between BEG...END and no line was found to be larger
> than MAX_SEEN_LINE_LENGTH".  So it requires keeping track of a BEG..END
> (BEG can be an integer but END would likely be an (insert-before)
> marker) plus an integer keeping track of MAX_SEEN_LINE_LENGTH.
> Initially BEG is 1 and END is Z.

I don't understand how you keep track of BEG and END, in general.  E.g.,
deletion of a single character can in some cases reset BEG to 1 and END to
Z, right?

> I can't think of a good way to detect when MAX_SEEN_LINE_LENGTH can be
> made smaller, tho, so we might still need to rescan the whole buffer
> every once in a blue moon.

That, too, is a complication.  Once again, there's absolutely no reason to
scan more than a limited region around point where redisplay is likely to
look.  Scanning the entire buffer is a waste, and can potentially degrade
performance in very large buffers without any long lines.

Previous Next

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