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

[Eli Zaretskii]

> Date: Thu, 27 Aug 2015 17:05:35 +0000
> From: Pip Cet <pipcet@gmail.com>
> Cc: martin rudalics <rudalics@gmx.at>, 21333@debbugs.gnu.org
> 
>     > 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.

That's a different situation, quite bizarre btw.

Just run normal code, like only the message above, then move the
cursor, and you will see the echo area shrink back.  That's the normal
use case.

>     > 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'd say just don't do that, it's terribly annoying to see such display
even without the other issues.

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

What do you mean by "inconsistent state"?