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

[martin rudalics]

> I understood Eli differently. If I'm not misquoting him, his suggestion was
> to "simply recompute the coordinates every time they are needed". My
> objection to that is that in many applications, you don't know when the
> coordinates will be needed without changing other programs.

There's no need to ever recompute coordinates.  They are here all the
time.  What's needed is to record previous coordinates and to compare
them with the actual ones.

>> 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.
>
> Would (window-size) return the old or the new size values?

All existing functions (like ‘window-size’) would obviously remain
unchanged.  We would provide a new function, say ‘window-old-size’, to
return the width or height of a window at the time the last redisplay
finished.

> Is there consensus for keeping pre-redisplay-function?

Sure.  It's been only added in 2013.

> windows.texi:
> @defvar window-configuration-change-hook
> A normal hook that is run every time you change the window configuration
> of an existing frame.  This includes splitting or deleting windows,
> *changing the sizes of windows*, or displaying a different buffer in a
> window.

Damn.

> I think it's at least possible to read that as applying to window resize
> operations.

At least.

>>>    - document set-window-configuration doesn't call
>>> window-size-change-functions if nothing changed
>>
>> No (because IIRC we never document fixed bugs).
>
> Are you sure? It occurs to me I should have said "remove the bit in the
> documentation that says window-size-change-functions is always called by
> set-window-configuration". It's not about documenting the bugfix, but
> undocumenting the old bug.

You're right again.  I suppose that what we wanted to say there is that
we always call ‘window-configuration-change-hook’.

>>>    - 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.
>
> That's why I consider it "wishlist". My Christmas wish is to be told
> whenever the X rectangle corresponding to my Emacs window has changed, just
> before the X server is told about the change.

I still don't understand: Do you mean that ‘pre-redisplay-function’ is
called in the wrong place?  Where else would you call it?

> Should that be impossible? As far as I can tell, the documentation reads
> like it should be possible. At least some people make use of it, if in ways
> you probably think useless.
>
> I consider the documentation to be more authoritative than current
> behavior: if a feature should work according to the documentation, but
> doesn't, I think the right thing to do is almost always to fix the feature
> and then, afterwards, discuss whether it should be removed.

If we can fix the feature, yes.

>>>    - mark window-size-change-functions as obsolete and see whether
>>> anyone complains?
>>
>> This will happen if we don't provide a good subsitute.
>
> Wait, don't you mean that will happen if we do provide a good substitute?

If ‘pre-redisplay-function’ can do the job it's a good substitute.

>>> +            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.
...
> Reasons for calling pre-redisplay-function in these cases: Mouseover, if
> you need more than text properties give you. Cursor warping. X hacks. It's
> what the previous code did, so I didn't dare change it.

But this would imply that we also had to care about the case where a
window's body width or height changes.  Discriminating that is pretty
difficult since we don't store that in a window configuration.  And even
the body width remains unchanged when I move a window's scroll bar from
the left to the right.

martin