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

[Eli Zaretskii]

> Date: Sat, 13 Oct 2012 19:45:20 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@iro.umontreal.ca, 12600@debbugs.gnu.org
> 
>  >> (1) Change the window's buffer via `set-window-buffer'.
>  >
>  > This is taken care of by setting windows_or_buffers_changed.
> 
> windows_or_buffers_changed is a global flag.  How does redisplay find
> out _which_ window got a new buffer?  Or does redisplay not care?

It doesn't care, in the sense that it always considers every window.
It _does_ care, in the sense that certain redisplay optimizations are
turned off when windows_or_buffers_changed is non-zero.

E.g., if nothing's changed since the last redisplay, then redisplay
will only enter try_cursor_movement for each window, quickly see that
point didn't move, and exit without doing anything.  But if
windows_or_buffers_changed is non-zero, this optimizations is
disabled.

>  >> (2) Change the size of the window (including toggling of scrollbars and
>  >>      fringes).
>  >
>  > Redisplay figures this out already, I think.  Which commands/functions
>  > make these changes?
> 
> They all end up calling window_resize_apply.

They all also set windows_or_buffers_changed non-zero.  So I think
these cases are already covered, as far as redisplay is concerned.

> 
>  >> (3) Change the buffer's position in the window (usually via scrolling,
>  >>      `set-window-point' and `set-window-start').
>  >
>  > These likewise set windows_or_buffers_changed, so they shouldn't be a
>  > problem.
> 
> But usually they affect only one window.  Again, redisplay might not
> care.  But I would be surprised that it doesn't handle such a simple
> case of optimization.

It tries.  It disables fewer optimizations when last_modified is reset
than when windows_or_buffers_changed is non-zero.  But I doubt that
this difference shows in many important situations.  At least resizing
a window never affects only one window.

>  >> Now in all of these cases, the respective routines in window.c would set
>  >> the window's last_modified_flag to t, marking the window as dirty.
>  >
>  > I don't think this is necessary.  Can you try without setting this
>  > flag, and see if anything breaks?
> 
> I said "would".  last_modified_flag doesn't exist.

The same should be tru for the last_modified and last_overlay_modified
fields, which do exist.

>  >> So why do we currently reset last_modified and last_overlay_modified in
>  >> window.c?
>  >
>  > See above.  Maybe I'm missing something, but
>  > windows_or_buffers_changed should take care of all of this.
> 
> OK.  I'll comment them out after the feature freeze and we'll see ;-)

Thanks.

> Replace the three struct members last_modified, last_overlay_modified
> and window_end_valid by one struct member called last_modified_flag -
> actually calling it window_modified would be better.  Set
> window_modified to t wherever we currently reset one of the three
> members.  Redisplay, when fully done, would reset window_modified to nil
> for every window it completes instead of setting the other members.

And when a buffer is modified or its overlays are modified, what
should we do to indicate to redisplay that the corresponding windows
might need a more thorough redisplay?