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

[martin rudalics <rudalics@gmx.at>]

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

(2) Change the size of the window (including toggling of scrollbars and
     fringes).

(3) Change the buffer's position in the window (usually via scrolling,
     `set-window-point' and `set-window-start').

There might be indirect changes as well (e.g., when setting a window
display property) but let's stick to the three cited above.  All these
require usually a complete redisplay of the buffer in the window.  There
is one exception, namely when `split-window-keep-point' is nil,
`split-window-below' tries to keep the old display (but I doubt that
this works with variable height fonts and it will likely fail as soon as
we split windows pixel-wise).

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.  When
resizing or splitting windows, usually more than one window is affected;
for scrolling usually one window is affected.  When the display engine
scans windows, it has to redisplay a window when the flag is set,
resetting the flag when it's done.  Otherwise, it will redisplay the
window iff the buffer's modification flag says so.

Note that the last_modified_flag of the window covers both last_modified
and last_overlay_modified as far as the window's redisplay is concerned.

`window-end' with non-nil UPDATE requires a different treatment anyway
because it inspects a cached value that is invalidated either by a
buffer modification or a window change.  Hence the only simple solution
for this is to reset window_end_pos to nil whenenver we set that
window's last_modified_flag.  `window-end' then would update
window_end_pos either if it is nil or the buffer was modified since the
last redisplay.

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

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

martin