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

Previous Next

Full log

Message #1774 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:50:39 -0400

Stefan Monnier [2022-08-16 17:42:45] wrote:
> 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,

And actually, it doesn't seem to be slowed by long lines, only by the
buffer size.  So its `widen` should definitely override the
line-length-induced narrowing (tho maybe not the buffer-size-induced
narrowing if/when we add such a thing).


        Stefan

Previous Next

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