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

[Eli Zaretskii]

> Date: Tue, 16 Oct 2012 11:39:37 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@iro.umontreal.ca, 12600@debbugs.gnu.org
> 
>  >> BTW, I meanwhile discovered that the update_mode_line field (with a
>  >> misleading comment IIUC) is the canonical approach to ask for
>  >> redisplaying a specific window.
>  >
>  > That's not my reading of the code.  The w->update_mode_line flag, if
>  > non-zero, forces redisplay of the mode line, and also of the menu bar
>  > and the tool bar, of that window.  Where did you see that its effect
>  > is to redisplay the whole window?
> 
> Because the doc-string for Fforce_window_update says "If optional arg
> OBJECT is a window, force redisplay of that window only." but the code
> does
> 
>        mark_window_display_accurate (object, 0);
>        w->update_mode_line = 1;
>        if (BUFFERP (w->buffer))
>       XBUFFER (w->buffer)->prevent_redisplay_optimizations_p = 1;
>        ++update_mode_lines;
> 
> and does not set windows_or_buffers_changed.  So apparently the above
> (and not only setting w->update_mode_line to 1 as I concluded
> incorrectly) are sufficient to force the redisplay of a single window
> (including all windows showing the same buffer).

Yes.  The prevent_redisplay_optimizations_p flag is the crucial detail
here.

>  > force-window-update with a window as its argument just marks that one
>  > window's display "inaccurate", requests redisplay of its mode-line,
>  > and prevents optimizations of any other window displaying the same
>  > buffer.  Windows that don't display this buffer can still avoid some
>  > or all of redisplay through optimizations.
> 
> That's the case I had in mind.  So if I follow you correctly,
> set_window_buffer could instead of doing
> 
>    windows_or_buffers_changed++;
> 
> call Fforce_window_update with the window whose buffer gets set as its
> argument.

Yes, I think so.