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

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, dgutov <at> yandex.ru
Subject: bug#56682: locked narrowing
Date: Fri, 02 Dec 2022 08:54:31 +0000

>>> Maybe another option is to do the scan more lazily, keeping track more
>>> precisely of what was scanned and/or needs rescanning.
>>
>> Thanks.  It's an option indeed, the problem here is how to keep track 
>> of what was scanned or needs rescanning.
>
> 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'm not sure I understand how that would work, concretely.  After the 
initial scan, we would have beg=BEG / end=Z.  Now the buffer is modified, 
say 1000 characters are added at position 1000 and 10000 characters are 
added at position 10000.  What would be the values of beg and end after 
these two operations?  The two portions of the buffer that did not change 
are BEG .. 1000 and 20000 .. Z, so it seems to me that it's better to keep 
track of the portion of the buffer that did change, in this case 1000 .. 
20000.

Previous Next

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