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: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, dgutov <at> yandex.ru
Subject: bug#56682: locked narrowing
Date: Wed, 30 Nov 2022 13:52:48 +0000

>> After looking at this closely, it turns out that the change in 
>> 1c837c42c2 doesn't do what it was meant to do.  Sigh...  Dmitry, can 
>> you confirm that the following change fixes this?
>
> ??? You are reverting what I believe was a fix for bug#57207, right?
>

No, I'm not reverting, I'm fixing.  The condition before 1c837c42c2 was 
"MODIFF - UNCHANGED_MODIFIED > 8", with 1c837c42c2 it became "CHARS_MODIFF 
- CHARS_UNCHANGED_MODIFIED > 8", which appeared correct at that time but 
is not, with the patch it becomes "CHARS_MODIFF - UNCHANGED_MODIFIED > 8".

>
> How did you reach the conclusion that the change doesn't do what it was 
> supposed to? please tell more about what you saw and your conclusions.
>

The first condition triggered the long line detection too much: it was 
triggered when the the only changes in the buffer were fontification 
changes.  The second condition fixes that problem, but still triggers the 
long line detection too much: it is still triggered when the main (but not 
_only_) changes in the buffer are fontification changes, IOW, it is 
triggered even if a single character is inserted and "enough" 
fontification changes are made.  The condition in the patch is correct: 
the long line detection mechanism is triggered only when many characters 
are inserted.

Previous Next

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