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

Previous Next

Full log

Message #1771 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, dgutov <at> yandex.ru
Subject: Re: locked narrowing
Date: Tue, 16 Aug 2022 17:42:45 -0400

Gregory Heytings [2022-08-16 20:23:46] wrote:
> Another comment:
>> diff --git a/nlinum.el b/nlinum.el
>> index 4f0e02fef1..3feaaca5c3 100644
>> --- a/nlinum.el
>> +++ b/nlinum.el
>> @@ -312,7 +312,7 @@ Only works right if point is at BOL."
>>   (if nlinum-widen
>>       (save-excursion
>>         (save-restriction
>> -          (widen)
>> +          (REALLY-widen)
>>           (forward-line 0)              ;In case (point-min) was not at BOL.
>>           (let ((nlinum-widen nil))
>>             (nlinum--line-number-at-pos))))
> FWIW, that's not a good example, because it's a bad idea to calculate line
> numbers in buffers with long lines or with too many lines: it takes too
> much time.

In my tests, it works fast enough for pretty large buffers and pretty
long lines, so while the above might be too crude, the limits we should
use for it should be much lower than `syntax-wholeline-max` and even
probably larger than `large-file-warning-threshold`.


        Stefan

Previous Next

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