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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 25 Aug 2015 09:25:14 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 21333@debbugs.gnu.org
> 
> > 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.

In these two cases, yes.  In all the others (which are vast majority),
no.

And I'm still not sure I understand the relevance.  How exactly
knowing about the automatic resize will help with coordinates in this
case?  If the Lisp program recomputes coordinates inside the hook, it
will get the same results in most cases (when point is not in the
obscured lines).  So an alternative that doesn't need any hook is
simply to recompute the coordinates every time they are needed.  It's
not like this calculation is expensive, is it?

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

Yes, of course.

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

And we get regular complaints about that as well.  Moreover, the
setting of the modified status by fill-paragraph is just an annoyance
that doesn't cost anyone any extra complexity, whereas the situation
with this and similar hooks costs us quite a lot in that aspect.