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

[martin rudalics <rudalics@gmx.at>]

 > But the coordinates of the text that stays on screen don't change in
 > such a resize.  Some text is obscured, but what's left doesn't move.
 > So I see no problem here.

I'm not sure what you mean here: When the minibuffer resizes and point
is near the bottom of the window above, the window above will scroll and
stick to the new window start position even after the minibuffer gets
sized back.  When the window above the minibuffer is a one line window
or fixed-size, the window above that window will be subject to those
changes.

 > No, it's not.  It's the same issue: this hook is already called in
 > situations where it shouldn't have been, and thus imposes on the
 > programmers who use it complex ways of deciding whether there was or
 > wasn't a change they should care about.  You suggest to add one more
 > situation in that class, something that most application that define
 > this hook shouldn't and don't care.  It's the complexity that worries
 > me.

You mean when ‘set-window-configuration’ doesn't change the size of a
single window the hook shouldn't be called?  Ideally it shouldn't but
this is a problem similar to that of indenting a paragraph changing the
buffer modified state although in reality nothing changed.

martin