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

[Eli Zaretskii]

> Date: Fri, 12 Oct 2012 09:32:01 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: cschol2112@gmail.com, 12600@debbugs.gnu.org
> 
> Before doing that, could you please in window.h eventually update the
> comments for display related fields like last_modified,
> last_overlay_modified, last_point to say who's supposed to (re-)set them
> to which value.

I would like to, but I need some guidance as to what is unclear, see
below.

> I'm afraid the current situation is a mess.

I can agree to that.  Quite a few struct members related to the
display engine (and I suppose other core structures as well) are
insufficiently, in accurately, or even downright incorrectly
documented.  I try to fix every such problem I bump into, FWIW.

> For example, what does the "displayed buffer's text modification events
> counter as of last time display completed" mean?

This one sounds quite clear, please tell which part needs further
clarifications.  It would be better to say "counter of the displayed
buffer's modification events as of last time display completed", but
somehow I'm guessing it's not what you had in mind.

> Suppose redisplay has set this to 37.  Apparently, setting it to 36
> means that the next redisplay will notice that for this window
> display is not accurate and has to be redone because 36 < 37.

Not necessarily.  It depends on what is recorded in the buffer's
BUF_MODIFF slot.

> But why is a flag insufficient to accomplish that?  IIUC it's set only
> once by mark_window_display_accurate_1 and everywhere else reset to 0.
> Why can't we set it to "accurate" in mark_window_display_accurate_1 and
> "inaccurate" everwhere else?

How would this work when the displayed buffer is modified behind
redisplay's back?  The last_modified slot belongs to the window, which
redisplay controls, but it doesn't control the buffer, which could
well be displayed in other windows as well and modified through there.
The display engine treats each window separately; when it displays
some window, it doesn't use information from other windows.

> And why do we have additional fields for last_overlay_modified and
> window_end_valid?  What sense does it make to handle these separately?

Because changes in overlays do not constitute changes in buffer
contents, and are done via yet another set of primitives, yet they do
require redisplay.  Also because each one of these can allow and
disallow certain distinct redisplay optimizations, at least in
principle.

As for window_end_valid flag, it's there to allow yet another set of
redisplay optimizations.

> For example, wherever last_modified is reset to 0 last_overlay_modified
> is always reset to 0 too.  Isn't that plain overkill?

The potential for separate optimizations is not realized, that's true.
But it exists; I'm not sure we should remove it, and I surely won't
spend any of my personal time trying.  Fixing real bugs in the display
engine is enough to fill my free time already.  Of course, if you feel
like it, and if no one objects, feel free to make these cleanups.