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

[martin rudalics <rudalics@gmx.at>]

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

Naively spoken it's obvious that when you shrink the minibuffer you show
more lines in the window above and ‘linum-mode’ has to add numbers for
those lines.  And when you enlarge the minibuffer, ‘follow-mode’ will
lose some lines at the bottom of the left window and has to show them at
the top of the right window.

I don't know how these packages currently work around the problem that
‘window-size-change-functions’ is not called for automatic minibuffer
resizing.  Maybe they use the ‘post-command-hook’ function instead.

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

This is, in fact, an abuse of ‘set-window-configuration’.  But how fix
it?  We'd need a hook, say ‘window-size-change-functions’, that tracks,
among other things, whether a window was resized due to a change of the
minibuffer height and, if that happens, set a flag to indicate that the
window configuration must be restored.

martin