GNU bug report logs - #56393
Actually fix the long lines display bug

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
Subject: bug#56393: Actually fix the long lines display bug
Date: Sat, 09 Jul 2022 12:13:35 +0300

> Date: Sat, 09 Jul 2022 08:24:38 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: larsi <at> gnus.org, Gerd Möllmann <gerd.moellmann <at> gmail.com>, 
>     56393 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.