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

Previous Next

Full log

Message #467 received at 56393 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 56393 <at> debbugs.gnu.org
Subject: Re: bug#56393: Actually fix the long lines display bug
Date: Tue, 19 Jul 2022 08:53:12 +0000

Thanks again for your detailed comments!

>
> - Since the determination is done in what I'd call redisplay, what if a 
> buffer with long lines is never, or not yet, displayed?  Are there 
> circumstances under which we are using an iterator then?  Background 
> fontification?  Some hook? Other stuff I don't know about?  Could that 
> cause us trouble?
>

If a buffer with long lines is never or not yet displayed, the specific 
optimizations do not take place.  That was a very important if not 
critical improvement, because Emacs may internally use buffers with long 
lines, and they should be entirely unaffected by that change.  (For 
example, the newsrc.eld file used internally by Gnus contains one such 
long line; if the same temporary restrictions were used in that buffer, it 
is possible that Gnus would not work correctly anymore.)

As far as I can tell, iterators are used in such buffers, too, but they 
are not fontified.  Fontification happens only when necessary, that is, 
when the buffer is actually displayed.

>
> - I did not see that l_l_o_p is set to false anywhere.  Should it be? 
> What if a buffer is modified in such a way that there are no long lines 
> anymore?
>

Gosh!  That was an error, thanks!

>
> - I don't understand this in redisplay_window:
>
>  /* Check whether the buffer to be displayed contains long lines.  */
>  if (!NILP (Vlong_line_threshold)
>      && !current_buffer->long_line_optimizations_p
>      && Z - BEG - BUF_UNCHANGED_SIZE (current_buffer) <= 1)
>
> Does the last line mean "buffer got smaller"?  Sorry if I'm dense here, 
> but I don't get it.
>

It is (- (point-max) (point-min) (buffer-size-after-last-redisplay)), so 
it means "the buffer got larger by more than one character".  (Note that 
(buffer-size-after-last-redisplay) is a fictional function.)  But after 
discussing this with Eli I'm not convinced that it's a good enough 
heuristic.  The previous heuristic was simply "the buffer contents have 
changed", and I wanted to refine it a bit.

Previous Next

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