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

[martin rudalics <rudalics@gmx.at>]

 >>> 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?
 >>
 >> Correct.
 >
 > I disagree, if I understand correctly.

My "correct" referred to Eli's "It's not like this calculation is
expensive, is it?".  I suppose we all agree on that.

 > The coordinates might be passed
 > to another program, for example, and then we simply don't know when
 > that program decides to use them, so we still need a way to update our
 > (and its) idea of what the window size and position is, in my opinion.

I don't understand you here.  IIUC Eli means that any application can
store the old coordinates somewhere and easily compare them to the
current ones in order to detect whether window sizes have changed.

Even simpler: We could store the sizes in the window structure.  This
way prepare_menu_bars would simply walk the window tree of each frame to
detect whether the size of any window has changed, call the functions on
‘window-size-change-functions’ and afterwards (better when redisplay
completed) store the current size values into the old ones.  The
functions on the hook, OTOH, could check for each window individually
whether and how its size changed.  The advantage of this approach is
that we never accumulate any fake size changes.

 >> So ‘window-size-change-functions’ is dispensable.
 >
 > Iff we keep/fix pre-redisplay-function, I agree. I had, wrongly,
 > assumed that pre-redisplay-function is run many times per redisplay
 > call, but that appears to be incorrect. The huge majority of
 > redisplays call it just once, and that makes the overhead negligible.

We can declare ‘window-size-change-functions’ obsolete and suggest to
use ‘pre-redisplay-function’ instead.  Still we'd have to support it for
quite some time.

 > So what's the way forward, assuming my paperwork ever gets here?
 >   - document window-size-change-functions aren't called for mini-window resizes

... and maybe neither when the menu or tool bar wrap.

Yes (if we decide to not change anything else).

 >   - document window-configuration-change-hook isn't called for
 > mini-window resizes

No (because we nowhere say that `window-configuration-change-hook' is
called for resize operations).

 >   - document set-window-configuration doesn't call
 > window-size-change-functions if nothing changed

No (because IIRC we never document fixed bugs).

 >   - fix set_window_configuration not to set the window size change flag
 > unless there was an actual size change

Unless we decide to move that check to prepare_menu_bars as I sketched
above.

 >   - wishlist item: call pre-redisplay-function between
 > grow/shrink_mini_window and the actual X repaint, rather than before.

Are you sure?  If prepare_menu_bars is called before auto-resizing the
minibuffer window, then ‘window-size-change-functions’ wouldn't catch
those auto-resizes either.

 >   - mark window-size-change-functions as obsolete and see whether
 > anyone complains?

This will happen if we don't provide a good subsitute.

 > +            if (w->pixel_left != XFASTINT (p->pixel_left) ||
 > +                w->pixel_top != XFASTINT (p->pixel_top) ||
 > +                w->pixel_width != XFASTINT (p->pixel_width) ||
 > +                w->pixel_height != XFASTINT (p->pixel_height))

You still didn't explain why you find it necessary to compare the
pixel_left and pixel_top values.

martin