emacs-devel
[Top][All Lists]
Advanced

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

Re: Latest changes in redisplay code


From: Dmitry Antipov
Subject: Re: Latest changes in redisplay code
Date: Tue, 05 Feb 2013 09:52:11 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2

On 02/04/2013 08:25 PM, Eli Zaretskii wrote:

This change loses the ability to track the buffer whose line numbers
are being displayed on the mode line.  This means we will now never
show line numbers in this window, even after the buffer it displays
changes.  (I just tried that, and it really is so -- another bug.)

Could you please provide an example? I don't see the way to reproduce it.

IIUC the logic for w->base_line_pos before 111647 was:

 nil) initial state, redisplay should calculate it;
 number) calculated by redisplay and so valid, always > 0;
 w-buffer) redisplay has decided that line numbers aren't
 appropriate for w->buffer.

If w->base_line_pos is a number, it maps to:

 0) initial state;
 >0) valid;
 -1) line numbers aren't appropriate.

Note that adjust_window_count tracks all w->buffer changes and invalidates
w->base_line_pos to initial state.

          /* If the buffer is very big, don't waste time.  */
          if (INTEGERP (Vline_number_display_limit)
              && BUF_ZV (b) - BUF_BEGV (b) > XINT (Vline_number_display_limit))
            {
   -        wset_base_line_pos (w, Qnil);
   -        wset_base_line_number (w, Qnil);
   +        w->base_line_pos = 0;
   +        w->base_line_number = 0;
              goto no_value;
            }

You set base_line_pos here to zero, not to -1: why?

Because original code sets it to nil.  I suspect that it's needed to reconsider
base_line_pos for the next redisplay if the buffer was changed.

Revision 111584 also has a suspicious change:

   @@ -3189,7 +3182,7 @@ set_window_buffer (Lisp_Object window, L
      wset_window_end_pos (w, make_number (0));
      wset_window_end_vpos (w, make_number (0));
      memset (&w->last_cursor, 0, sizeof w->last_cursor);
   -  wset_window_end_valid (w, Qnil);
   +

Why was this setting dropped?

And what about these two:

   @@ -13758,7 +13756,7 @@ mark_window_display_accurate_1 (struct w
         else
          w->last_point = marker_position (w->pointm);

   -      wset_window_end_valid (w, w->buffer);
   +      w->window_end_valid = 1;
   @@ -27782,7 +27779,7 @@ note_mouse_highlight (struct frame *f, i
        And verify the buffer's text has not changed.  */
      b = XBUFFER (w->buffer);
      if (part == ON_TEXT
   -      && EQ (w->window_end_valid, w->buffer)
   +      && w->window_end_valid

Why don't we need to assign a buffer to w->window_end_valid?  What
purpose did this value serve, and why did you decide it was no longer
needed?

This is similar to base_line_pos. Before 111584, w->window_end_valid was:

nil) redisplay has not been completed;
w->buffer) redisplay has been completed for _this_ window showing _that_ buffer.
So, if w->buffer is not the same as w->window_end_valid, w->buffer was changed
since last redisplay.

Now it is:

0) redisplay has not been completed
1) redisplay has been completed. We do not need to save the buffer for which
it was completed, it's always w->buffer; any assignment to w->buffer
is tracked by adjust_window_count which invalidates w->window_end_valid.

How can we make this process less dangerous?

Hm. Although I agree that I had to test 111647 more carefully, there always will
be the things which can't be tested by just one developer (like 111594, for 
example).
As for the redisplay, automated testing is practically impossible; at least, it 
would
be nice to have a set of "non-typical" (beyond basic editing) use cases which 
should
trigger some corner-case situations.

Dmitry



reply via email to

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