bug#56682: locked narrowing

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> My suggestion was to have as "steady state" that "everything is scanned
>> except for a region between BEG...END and no line was found to be larger
>> than MAX_SEEN_LINE_LENGTH".  So it requires keeping track of a BEG..END
>> (BEG can be an integer but END would likely be an (insert-before)
>> marker) plus an integer keeping track of MAX_SEEN_LINE_LENGTH.
>> Initially BEG is 1 and END is Z.
>
> I don't understand how you keep track of BEG and END, in general.

Every buffer modification updates it.

> E.g., deletion of a single character can in some cases reset BEG to
> 1 and END to Z, right?

No, why would you think so?
Any change at position POS would set BEG to (min BEG POS) and END to (max
END POS) (modulo marker-position updates for END).

I now realize that a deletion can increase line length by removing LF
chars, so the condition I proposed to decide when a rescan is needed
would need to be adjusted, but the basic idea still stands.

>> I can't think of a good way to detect when MAX_SEEN_LINE_LENGTH can be
>> made smaller, tho, so we might still need to rescan the whole buffer
>> every once in a blue moon.
> That, too, is a complication.

For the 99% of the buffers the MAX_SEEN_LINE_LENGTH should stay small
"for ever" so it's probably not a big issue.

> Once again, there's absolutely no reason to scan more than a limited
> region around point where redisplay is likely to look.

Indeed, that's another possible approach.

> Scanning the entire buffer is a waste, and can potentially degrade
> performance in very large buffers without any long lines.

The full-buffer scan would only be needed once when inserting the file
into the buffer, so it's not clear it would degrade performance in any
significant way, but if needed we can make it more lazy by keeping track
(in addition to the "beg..end of not yet scanned changes") of the
"beg..end of region already scanned" so we only scan the part of the
buffer actually visited (which will still degenerate to "the whole
buffer" if we display BOB and then EOB, of course, as usual).


        Stefan