bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56682: locked narrowing


From: Eli Zaretskii
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@heytings.org>
> cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]