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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.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 09:05:52 +0200

> Date: Thu, 01 Dec 2022 22:23:38 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, dgutov <at> yandex.ru
> 
> > But anyway, what exactly does this prove, and how?  I asked why we need 
> > to look beyond the narrowing, so how does the above answer that 
> > question? what am I missing?
> 
> 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.

> 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.

Previous Next

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