bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame

[Eli Zaretskii]

> Date: Sun, 14 Oct 2012 20:33:39 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@iro.umontreal.ca, 12600@debbugs.gnu.org
> 
>  > How do you know whether the window's buffer was modified, under your
>  > suggestion?  Won't we need some record of "the last buffer state when
>  > this window was displayed"?  E.g., how do we know that point moved
>  > since last full redisplay of the window?
> 
> If we do not know whether point moved in a buffer since its last
> redisplay, we probably can't optimize anything at all.

We do know, but only because we record that (in w->last_point).

> But we already
> got MODIFF, CHARS_MODIFF, and OVERLAY_MODIFF.  What are these good for
> if we always have to redisplay a window showing a buffer whose point
> could have moved since the last redisplay?

Those MODIFF features record actual changes, not cursor motion.

> But apparently
> try_cursor_movement handles this if I understand your text below
> correctly.  So why are you asking this?

Because I don't understand your plan to redesign these variables and
flags.  I don't see the big picture.

>  >> (3) Don't redraw the window otherwise.  This would cover the case where
>  >>      `point' was moved in a buffer not shown in this window or another
>  >>      window was scrolled.
>  >>
>  >> This would replace checking of windows_or_buffers_changed with a
>  >> finer-grained has "this window or its buffer changed".  But after a
>  >> cursory look at redisplay_window I doubt that such a change would be
>  >> feasible.  And I have no idea to which extent (3) is already covered by
>  >> try_window_id.
>  >
>  > The normal "do-nothing" route is to call try_cursor_movement,
> 
> So try_cursor_movement cares about the no buffer change, no overlay
> change, no window change, no font change, ... only point movement case.

No, it is only _called_ when there are no changes of the kind you
mention above.  If any of these changes are detected,
try_cursor_movement is bypassed, since it is known that it will not do
the job.  Here:

  /* Handle case where text has not changed, only point, and it has
     not moved off the frame, and we are not retrying after hscroll.
     (current_matrix_up_to_date_p is nonzero when retrying.)  */
  if (current_matrix_up_to_date_p
      && (rc = try_cursor_movement (window, startp, &temp_scroll_step),
          rc != CURSOR_MOVEMENT_CANNOT_BE_USED))
    {
      switch (rc)
        {
        case CURSOR_MOVEMENT_SUCCESS:
          used_current_matrix_p = 1;
          goto done;   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

        case CURSOR_MOVEMENT_MUST_SCROLL:
          goto try_to_scroll;

        default:
          emacs_abort ();
        }
    }

The marked line is the "green channel".  It is taken only if
try_cursor_movement succeeds.

And current_matrix_up_to_date_p is computed thusly:

  current_matrix_up_to_date_p
    = (!NILP (w->window_end_valid)
       && !current_buffer->clip_changed
       && !current_buffer->prevent_redisplay_optimizations_p
       && w->last_modified >= MODIFF
       && w->last_overlay_modified >= OVERLAY_MODIFF);

>  > then
>  > "goto done".  try_window_id is called only if there's some change that
>  > requires redisplaying some of the text, not just moving the cursor.
> 
> That's what I meant earlier where you replied by asking "how do we know
> that point moved".  The various MODIFFs should tell me whether the
> buffer changed.  Some other settings tell me whether some font or the
> cursor type changed.  And window_modified tells me whether something in
> the window changed that requires to execute try_window_id.  If none of
> these changed, the window can stay alone.  All this would work only if
> point movement has been handled already.

I'm not sure I understand where you are getting, but to facilitate
this discussion, let me describe the logic of redisplay_window.  It
goes like this:

  . if nothing changed except possibly point, call
    try_cursor_movement; if that succeeds, we are done

  . otherwise, if the buffer is unchanged, try reusing some of the
    current glyph matrix, assuming that just the window-start has
    changed -- this is what try_window_reusing_current_matrix does

  . if that fails, call try_window_id, which tries reusing of the
    current glyph matrix, assuming that only some lines at the
    beginning or the end of the window have changed

  . if that fails, too, call try_window to redisplay the entire window
    using the previous window-start point

  . if try_window finds that point ends up outside the window,
    "scroll" the window, i.e. find a better window-start point such
    that point enters the window -- this is what try_scrolling does

  . if that fails as well, compute the new window-start and redisplay
    the entire window starting from there

> This would mean that try_cursor_movement had instead of
> 
>        && !windows_or_buffers_changed
> 
> check
> 
>        && !w->window_modified
> 
> and the respective MODIFF conjuncts for w's buffer.

What would we gain by this change?

> BTW, couldn't we instead of
> 
>        && !(!NILP (Vtransient_mark_mode)
>          && !NILP (BVAR (current_buffer, mark_active)))
> 
> use the more human
> 
>        && (NILP (Vtransient_mark_mode)
>          || NILP (BVAR (current_buffer, mark_active)))
> 
> here?

It depends on how you reason about logic.  To me, the condition

    !NILP (Vtransient_mark_mode)
     && !NILP (BVAR (current_buffer, mark_active))

is clear, whereas its reverse is less so.