bug#56682: locked narrowing

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  56682@debbugs.gnu.org,  dgutov@yandex.ru
> Date: Thu, 01 Dec 2022 18:48:26 -0500
> 
> Do an initial scan on the whole buffer and after that keep a BEG..END
> limit approximating the region that has been modified since the last scan.

We currently don't have any way of telling what was modified since the last
scan.

> As long as
> 
>    END - BEG < LINE_LENGTH_THRESHOLD - MAX_SEEN_LINE_LENGTH
> 
> then we know we don't need to rescan anything at all.  And when we do
> need to rescan we can limit the scan to
> 
>    BEG - MAX_SEEN_LINE_LENGTH ... END + MAX_SEEN_LINE_LENGTH
> 
> I assume here that we would remember the MAX_SEEN_LINE_LENGTH.

I hope we can come up with a less complicated scheme.

We only need to know whether there are long lines in a region around point
that is large enough to make sure redisplay won't look beyond that.
(Gregory disagrees, but I have yet to see a reason why he would be right and
I would be wrong in this matter.)  We know where the window's point was at
the time of the last redisplay, so we can detect when point moves "too far",
and trigger rescanning of the region around the new location of point --
this should be a condition in addition to those that currently guard the
rescanning loop.

Given the above, if the region we actually scan is not the entire BEGV..ZV
one, but has its size limited from above by some fixed value, the scanning
should scale much better for very large buffers, because the scanning loop
will never run more than a fixed upper bound of time.  The limit on the
region can be large enough to be safe, because the scan is very fast.  So
only extremely large buffers will not have all of their accessible portion
scanned, which is consistent with other measures we take to limit
potentially long processing using more or less arbitrary limits, like
syntax-wholeline-max, MAX_PARAGRAPH_SEARCH in bidi.c etc.  The result is
potential inaccuracy and/or degradation, but only in very rare cases.