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

[Pip Cet]

On Thu, Aug 27, 2015 at 3:25 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Date: Thu, 27 Aug 2015 09:59:04 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, 21333@debbugs.gnu.org
>
> >>>    - 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?

I don't understand much more, it seems: the original wishlist
feature. 

 

The call to grow/shrink_mini_window only recomputes data
about the windows for the next redisplay cycle.

No. It computes data about the windows for the cycle that's currently happening, that has already called prepare_menu_bars and will most likely not do so again. Note that grow_mini_window is called by redisplay_internal, via resize_mini_window, not just by display_echo_area.

If you set breakpoints on prepare_menu_bars, grow_mini_window, and redisplay_internal, the log is:

Breakpoint 12, redisplay_internal () at xdisp.c:13310
Breakpoint 10, prepare_menu_bars () at xdisp.c:11558
Breakpoint 11, grow_mini_window (w=0x12676a0, delta=15, pixelwise=true) at window.c:4491
Breakpoint 12, redisplay_internal () at xdisp.c:13310

The call order is that redisplay_internal calls prepare_menu_bars, then calls grow_mini_window, then performs the frame update. It doesn't go back to calling prepare_menu_bars, but it does call update_frame, and that actually does its job. If I stop just before the second redisplay_internal and x_sync(), the screen will be in a mildly inconsistent state.

When that next cycle comes, it will first call pre-redisplay-function

Yes. With a nil argument. I don't fully understand why.

 

and window-size-change-functions

No. Miniwindow resizes do not set the WINDOW_SIZES_CHANGED flag even if they resize other windows. window-size-change-functions won't be called on the next redisplay, and it might not be called again for a very long time.

 

, from prepare_menu_bars, and then, after the rest of redisplay finishes, actually perform the X repaint, by
calling update_frame.

No. The sequence is redisplay_internal, then prepare_menu_bars, then grow_mini_window, then update_frame.

Breakpoint 14, redisplay_internal () at xdisp.c:13310
Breakpoint 10, prepare_menu_bars () at xdisp.c:11558
Breakpoint 11, grow_mini_window (w=0x12676a0, delta=15, pixelwise=true) at window.c:4491
Breakpoint 15, update_frame (f=0x319fa40, force_p=false, inhibit_hairy_id_p=false) at dispnew.c:3055
Breakpoint 15, update_frame (f=0x30a6070, force_p=false, inhibit_hairy_id_p=false) at dispnew.c:3055
Breakpoint 15, update_frame (f=0x313cc58, force_p=false, inhibit_hairy_id_p=false) at dispnew.c:3055
Breakpoint 15, update_frame (f=0x12ac950, force_p=false, inhibit_hairy_id_p=false) at dispnew.c:3055
Breakpoint 14, redisplay_internal () at xdisp.c:13310
 

So it sounds like the wish has been granted already, no?

If

1. I use pre-redisplay-function, not pre-redisplay-functions or window-size-change-functions

2. I ignore its arguments and check all windows

3. I don't mind that one X update has already happened with the new sizes immediately beforehand

I get the behavior I want (modulo point 3). That's empirical, with the code that I posted that makes a window display its current size.

 

  Moreover, the scenario where "prepare_menu_bars is
called before auto-resizing the minibuffer window", and as result
"‘window-size-change-functions’ wouldn't catch those auto-resizes",
seems impossible.

I don't think it's impossible, I think it's clearly happening to produce the breakpoint order that I'm seeing. (This is speculation, but I think my call order only applies to minibuffer window resizes, as stated above, not echo area resizes triggered by message3. That might be wrong, though).