bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize

[Pip Cet]

On Thu, Aug 27, 2015 at 3:29 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> `follow-mode' has to synchronize the ‘window-end’ of one window with the
> ‘window-start’ of another.

Not when one of them is temporarily obscured by a resized mini-window,
IMO.

I think that is indeed a matter of opinion (and should thus be subject to customization), but I don't think we should assume that recursive editing invocations or long message scenarios are always short-lived.

> Since mini-window resizing can persistently
> change the end position of the first of these windows

Any command that clears the echo area will resize it back, AFAIK.  So
it's not persistent.

That's not what I'm seeing here. When I run:

(progn
  (run-with-timer 2 nil (lambda () (message "hi")))
  (run-with-timer 3 nil (lambda () (message "")))
  (read-from-minibuffer (make-string 3000 ?*)))

The minibuffer resizes once, when the read-from-minibuffer prompt makes it grow to its maximal size; it then stays at that size as the short message is being displayed, then restores the long minibuffer prompt without changing size again when the echo area is cleared.

 

> OT1H we do care about point being visible when its window is partially
> obscured by the mini-window and deliberately scroll the window in that
> case.  OTOH we'd say that `follow-mode' should not care about keeping
> its text coherent in that case.  Is that fair?

Yes.  In that situation, the user most probably reads the mini-window
text anyway, and if not, then she reads the text at point.  The
probability that she is reading the text that will be scrolled out of
view as result of the mini-window resize is IMO minuscule.

So if, for whatever reason, I have a timer function that displays a two-line message once a second (so the echo area never goes back to its single-line state), my follow-mode buffer will be and remain in an inconsistent state until I manually resize a window, when it will go back to a consistent state, but then if I cancel the timer (and the mini-window shrinks) it'll be in an inconsistent state again, and the only way out of that one is another manual window resize?

I think that last case is something we haven't considered yet: if I resize windows manually while the mini-window is enlarged, they will be in an inconsistent state when it goes back to normal, right?