bug#56393: Actually fix the long lines display bug

[Eli Zaretskii]

> Date: Sat, 09 Jul 2022 08:24:38 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, Gerd Möllmann <gerd.moellmann@gmail.com>, 
>     56393@debbugs.gnu.org
> > I see that you decided to produce the "restriction" in init_iterator, 
> > which would, of course, work, but IMO it has a disadvantage: 
> > init_iterator is called a lot, so computing the "restriction" in it 
> > should be very fast.  Your current implementation _is_ fast, but AFAIU 
> > its result is that we _always_ restrict the display code from seeing the 
> > entire buffer, even if there are no long lines in it, which I think is 
> > unnecessary.  The original implementation only did that when it detected 
> > a long line, and I think we should keep it that way, because the 
> > "restriction" will inevitably have some negative effects, however minor, 
> > on what we display.
> 
> I don't think we can detect long lines reliably enough.  The problem of 
> the original implementation is what Gerd mentioned: "What happens when 
> evaluating an expression in *scratch* that returns a really large result? 

That problem doesn't exist when you run the detection code at the
beginning of redisplay (either in redisplay_window or in start_display
or in init_iterator), because by the time redisplay runs the buffer
text was already updated by the insertion that is the result of the
evaluation.

> Or maybe in a Shell buffer some large output?" and similar cases, like 
> inserting the result of a shell command in the buffer.  Detecting long 
> lines in insert-file-contents is not enough to make sure that Emacs will 
> always continue to behave normally when a long line is on display.

I agree, but doing this in insert-file-contents was not what I had in
mind.

> Note that we the current implementation does not always restrict display 
> code from seeing the entire buffer, it does so in a few well-chosen 
> places, everywhere else the display code sees the entire buffer.

And this is enough to make Emacs responsive?  If yes, that's great.