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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 13 Oct 2012 11:51:46 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@iro.umontreal.ca, 12600@debbugs.gnu.org
> 
>  >> last_modifed_flag is a fictitious variable I would set when the window
>  >> changes.  When it's set, redisplay must redisplay the window.
>  >
>  > What do you mean by "window changes"?  And how would any code outside
>  > of the display engine know whether some change requires to redisplay a
>  > window?
> 
> There are three types of window changes we have to consider:
> 
> (1) Change the window's buffer via `set-window-buffer'.

This is taken care of by setting windows_or_buffers_changed.

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

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

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

>  > Anyway, I don't think the above is right.  Only the display engine
>  > should set this variable.  The display engine should figure out itself
>  > whether to redisplay a window, by using other means.  If it doesn't,
>  > that's a bug.
> 
> 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.

>  >> We'd obviously have an independent buffer_modified_flag.  A window must
>  >> be redisplayed if either buffer_modified_flag is set (modulo any
>  >> optimizations which I won't dispute here) or its last_modifed_flag is
>  >> set.
>  >
>  > But comparing the buffer's modiff with last_modified already
>  > accomplishes this, so what would be the purpose of converting
>  > last_modified to a boolean flag, and then introducing another struct
>  > member that acts exactly like last_modified does today?
> 
> The last_modified_flag struct member would replace three members that
> have very obscure semantics IMHO.

We are going in circles, so there must be some misunderstanding here.
Can you describe your complete change suggestion, wrt these flags?  In
particular, what about buffer_modified_flag, and how does it enter
this picture?