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

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Thu, 21 Jul 2022 18:01:01 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

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 14:40:36 +0000
>
> I don't think I understand why it should be problematic or unsafe to 
> limit the same loop we have to a smaller region of the buffer.
>

I see that you already changed the loop to scan from BEG to Z to only scan 
from BEGV to ZV; somehow I missed that change.  I don't think even that is 
correct: a command could insert text in the buffer outside of BEGV/ZV. 
While limiting the loop to a smaller region of the buffer looks like a 
reasonable thing to do, the question is: how can we determine that region? 
And I don't see how this can be done, because the detection code is called 
only when a buffer is about to be displayed, and at that moment we cannot 
know where characters were inserted in the buffer.  What the code does now 
is "if enough characters have been inserted in the buffer since last 
redisplay, check again whether the buffer contains long lines".

>
> It should be clear that triggering such long searches should not be too 
> hard.
>

The search is not that long, and it is not triggered for regular editing 
commands, e.g. while typing or when killing / yanking a line in a buffer.




This bug report was last modified 2 years and 8 days ago.

Previous Next


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