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

[martin rudalics]

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