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

[Eli Zaretskii]

> Date: Fri, 12 Oct 2012 11:35:57 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: cschol2112@gmail.com, 12600@debbugs.gnu.org
> 
>  > 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.
> 
> If these concern the display engine exclusively, there's no problem.

I think this is why these are there, yes.

> Problems arise when the window handling code is supposed to change them.

Like where and when?

>  >> 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.
> 
> That's exactly what I had in mind: Either something that corresponds
> textually to what is used in buffer.h or just mention the name of the
> corresponding field used in buffer.h.

OK, will do.

>  >> 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.
> 
> IIUC this can only increase monotonously

But BUF_MODIFF could also change, no?  And a window can display
another buffer, can't it?

> When last_modifed_flag is set, the window must be redisplayed.

Not exactly, but OK.

> OTOH when the buffer iself is modified it has to be
> redisplayed anyway because we hardly know where the change happened.

If course, we know: we know where the window begins and ends.

> So I don't see why such a comparison of counters is useful.  But
> maybe I'm missing something.

We probably both are, but what's the bottom line here?

>  >> 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.
> 
> I doubt whether such optimizations exist.

What, you mean in theory?  That's a strange opinion, as there are any
number of ways of optimizing redisplay.  In fact, there are comments
today in the display code that describe optimizations that could be
implemented, but never were.

> Suppose we could exclude a change to happen within the bounds of a
> window as for example a buffer displayed with a window starting at M
> and ending at N and an overlay modified at some position < M or > N.
> Wouldn't this require to associate each single overlay with a
> modification counter?

Maybe, but I doubt that would allow any gains.  To make use of these
counters, you'd have to examine every overlay; but as soon as you have
an overlay in hand, its buffer position is as easy to access as its
counter.

The problem with overlays is that overlays-at, next-overlay-change,
etc. are slow, not that we lack some info in the overlays themselves.

Anyway, it would seem to be bad design to have a _window_ flag that
would change when some text or overlay in a buffer is modified.  Emacs
separates between display-related structures and buffer-related
structures for a number of good reasons, the most important being that
they are modified and examined independently, and there's no 1:1
relation between buffers and windows.

> I think that a correct implementation would have for each window w
> 
> (w->last_modified < MODIFF) => (NOT (w->window_end_valid))
> 
> but strongly doubt that this implication holds currently.

You could try putting assertions like that in the code and see if they
fire.

> I don't intend to make any cleanups.  I'd like to have a simple routine
> we can use to reset any such structur members within window.c and have
> that DTRT.

Under what circumstances does window.c need to do that?

> Currently, `window-end' is clearly broken and we should fix it.

An optimization that sometimes does the wrong thing is easy to fix:
either discover a condition under which the optimization works, or
simply disable the optimization.