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: Gerd Möllmann
Subject: bug#56393: Actually fix the long lines display bug
Date: Tue, 19 Jul 2022 10:21:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin)

Gregory Heytings <gregory@heytings.org> writes:

>> That's only ~100 lines of code?  Can that be?  I'm suspecting that I
>> don't use Magit right, again.  Or something.
>>
>
> You're using Magit right: it's indeed a small fix.
>
> Your comments would be most welcome, of course.

First of all - I find your design idea really nice.  I think the
iterator layer, if you will, is the right place for this kind of
functionality.

Whatever.  Let me distinguish your code into the part that decides
whether to do something, and the part that then does it.  I'm currently
only thinking about the first part, the determination if to do
something.

What I see, please correct me if I'm wrong:

The determination is part of what I call Emacs' redisplay layer.
Rediplay_window sets buffer's long_lines_optimization_p flag to true,
under some condition.  (l_l_o_p flag is then used to let the iterator
layer do something, later.)

Mark_window_display_accurate computes unchanged_size as Z - BEG, which
is the buffer's size at that point.  m_w_d_a is called from
redisplay_internal, again under certain conditions, basically when a
thorough display has been completed successfully.

Questions I'm pondering are, and I'm not saying anything is wrong or
something, I'm just thinking about this, and I guess you have been
thinking about the subject longer than I have

- 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?

- 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?

- 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.


















reply via email to

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