bug#56682: locked narrowing

[Eli Zaretskii]

> Date: Fri, 02 Dec 2022 07:56:06 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru
> 
> >> 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.

Not _any_ kind of changes, no.  Only a few that we know about and track,
because redisplay needs to know about them.

> Stefan's proposed approach looks promising, however.

I explained why in my other messages why it sounds too complicated.

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

The same will happen when the user types several characters.  Which happens
more frequently than changes of narrowing, in most use patterns.

And once again, you simply _cannot_ access buffer text beyond BEGV..ZV
safely.  It's a ticking time bomb if you do.

Anyway, let's stop here and agree to disagree.  I'm sorry, but I cannot
afford this endless argument; I'm swamped with too many tasks that no one
else except myself seems to be doing, and this argument already took an
inordinate amount of my time and energy.  Please install your
UNCHANGED_MODIFIED patch, and I will get to improving the scalability of the
scanning loop when I have time.  Please don't install any other changes in
this regard except that one patch.

Thanks.