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

[martin rudalics <rudalics@gmx.at>]

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

Via ‘pre-redisplay-function’?  How does a well-behaved mode detect
whether it has to make "this happen automatically"?  By walking all
windows and checking whether their sizes, start and end positions
changed, I suppose.

 >> Maybe they use the ‘post-command-hook’ function instead.
 >
 > Of course, they do!  The flag of bad design.

IIUC they didn't have another choice before ‘pre-redisplay-function’ was
added.

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

Sure.  Nevertheless we would have to also track changes due to automatic
minibuffer resizing.

Alternatively, Fset_window_configuration could run a modified version of
‘compare-window-configurations’ to compare the current configuration
with the one to be restored and restore the old configuration iff these
differ.  I'm not sure whether this would be any cheaper, especially when
the configuration does change frequently.

martin