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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 23 Aug 2015 22:06:45 +0000
> From: Pip Cet <pipcet@gmail.com>
> 
> This is possibly only a documentation issue.

Possibly.

> Recipe: eval
> (progn (push (lambda (&rest args) (message "window size changed"))
> window-size-change-functions)
>     (message (make-string 3000 ?*)))
> 
> Expected result: a "window size changed" message.
> 
> Actual result: no such message.
> 
> The symptom is that the window size change function is not run after a
> mini-window size change.

Note that resizing the mini-window involves resizing of at least one
other window on the same frame.  So this is not exactly about the
mini-window.

> So far, I can produce this behavior only when the minibuffer or echo
> area grows to several lines; when it shrinks afterwards, my window size
> change function is called.

I don't see the message even when the mini-window shrinks back.  Are
you sure the message you see is not triggered by some other event?
It's way too easy to trigger it, see below.

> I cannot reproduce the behavior with other windows.

See above: at least one other window is resized in this recipe, so the
exemption is not about the mini-window itself, it's about any window
involved in resizing in this particular scenario.

> Is this a bug? The documentation says:
> 
>     [...] to be called if the size of any window changes for any reason.
> 
> Please correct me if I'm wrong, but when the minibuffer/echo area gets
> resized (and the windows on top of it, too), that counts as a change of
> size, I would say.

I believe the original reason for this is largely historical:
window-size-change-functions exists since Emacs 19.29, whereas
automatic resizing of mini-window was introduced in Emacs 21.  Since
Emacs before 21 didn't have the mini-window resizing functionality,
Emacs 21 was careful not to gratuitously trigger these functions by
something that is purely a new redisplay feature.

That said, I wonder whether changing the code now to call these
functions due to automatic resizing would make sense.  What would be
the real-life use cases for using that?

I believe window-size-change-functions is meant for taking notice of
resizes done by the user or some Lisp code, not for automated resizes
whose sole purpose is to allow some message be read in its entirety.
If you agree, then the current behavior will make sense to you.

If anything, IMO we should _reduce_ the number of unrelated events
that trigger a call to these functions.  For example, currently any
command that reads from the minibuffer will trigger it, because when
read-from-minibuffer exits, it restores the window configuration by
calling set-window-configuration, which is documented to trigger these
functions.  That just doesn't make any sense to me, since most reads
from the minibuffer don't resize any windows!

> If this is merely a documentation issue, the exception should be noted
> in the manual.

That's easy.  Deciding what's TRT in this case is harder.

> If this behavior is deliberate, I believe it is inconsistent to set
> FRAME_WINDOW_SIZES_CHANGED (f) in `resize-mini-window-internal'.

It's consistent if we adopt the POV that this feature only catches
resizes from Lisp code.