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

[Eli Zaretskii]

> Date: Fri, 12 Oct 2012 17:43:01 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, 12600@debbugs.gnu.org
> 
>  >> When last_modifed_flag is set, the window must be redisplayed.
>  >
>  > No: last_modifed_flag is (normally) only set at the end of redisplay, so
>  > the in the future you can check if redisplay is needed by comparing it
>  > with the buffer's modiff.
> 
> 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?

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.

>  >> assignment.  OTOH when the buffer iself is modified it has to be
>  >> redisplayed anyway because we hardly know where the change happened.
>  >
>  > But instead of going through all the windows that display this buffer,
>  > we just change the buffer's modiff, so it will cause all the
>  > (last_modifed_flag == modiff) checks to fail in the windows that display
>  > this buffer.
> 
> 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?