bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56393: Actually fix the long lines display bug


From: Gregory Heytings
Subject: 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]