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 10:11:17 +0000

>
> I think this is just one aspect of the issue.  The loop under this 
> condition "punishes" large buffers with no long lines because we search 
> the entire buffer top to bottom.  To make this scale better, I think we 
> should only search in some predefined vicinity of the window, perhaps 
> the same region to which we narrow the buffer when we do detect long 
> lines.  We can then repeat the search if point moves far away from its 
> last value.
>
> There's no need to search the whole buffer, that will cause delays in 
> very large buffers for no good reason.
>
> We've talked about this a few months ago, and you said fixing this was 
> part of your todo.  I think now is the time.
>

Yes, it was and still is part of my todo.  At that point of time I was not 
at all expecting that Emacs 29 would be released three months later. 
What I had and still have in mind is too large a change for Emacs 29, so 
at first glance I think for now we'll have to live with the current 
solution.

Note that, apart from Dmitry, nobody reported a problem with that 
detection mechanism, and Dmitry's recipe with which he spotted that 
problem does not reflect actual usage.  And note that with the patch I 
just sent even Dmitry's recipe is fixed.

I'll see if I can design something smaller which would be suitable for 
Emacs 29, however.

Previous Next

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