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: Fri, 02 Dec 2022 07:56:06 +0000

>> It proves that the long line detection loop must be executed on the 
>> whole buffer.
>
> No, it doesn't.  It shows that the conditions to re-examine buffer text 
> are incomplete and need to be augmented.
>

It does, and it's just an example of the general point I'm (apparently 
unsuccessfully) trying to convey: when redisplay is called, any kind of 
changes may have been made in the buffer at any point since last 
redisplay, and we cannot know where these changes occurred.  Stefan's 
proposed approach looks promising, however.

>> In this case there are no modifications to the buffer when it is 
>> widened, so the detection loop is not triggered, and because there was 
>> no long line in BEGV/ZV before widening Emacs did not activate the long 
>> line optimizations.
>
> You didn't explain the problem clearly enough, so I didn't understand it 
> originally.  The actual problem is not that the restriction changes 
> since the last redisplay, the problem is that the restriction changes 
> _and_ the number of unsaved buffer text modifications is still below the 
> threshold of 8.
>
> Once I understood the scenario, the fix was a simple one-liner, which I 
> installed yesterday night.
>

That fix is wrong, sorry.  Now the detection loop is triggered each time 
the user changes the narrowing, in the vast majority of cases for no good 
reason.

Previous Next

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