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

[Eli Zaretskii]

> Date: Mon, 24 Aug 2015 20:06:54 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 21333@debbugs.gnu.org
> 
>  > 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.

In well-behaved modes this happens automatically, as part of
redisplay.

> Maybe they use the ‘post-command-hook’ function instead.

Of course, they do!  The flag of bad design.

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

I'd say, don't set the "size changed" flag unless the size really
changed.