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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 27 Aug 2015 16:35:44 +0000
> From: Pip Cet <pipcet@gmail.com>
> Cc: martin rudalics <rudalics@gmx.at>, 21333@debbugs.gnu.org
> 
>     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.

That's exactly what I said, just in other words.

> Note that grow_mini_window is called by redisplay_internal, via
> resize_mini_window, not just by display_echo_area.

They are both called _after_ prepare_menu_bars.  So if
resize_mini_window, however it is called, sets the flag that windows
has been resized, only the next redisplay cycle will notice that and
call the window-size-change-functions.

> 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

I already did that, before writing my message.

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

Yes, and that is not what you want because?...

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

I was talking about the situation after you proposed changes, which
will cause the flag to be set (AFAIU).

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

But grow_mini_window only recomputes the start of the window, it does
not redisplay it.  The next cycle will.

The function update_frame only reflects on the glass what its
redisplay cycle computed to be the desired display.  If redisplay
didn't recompute the window contents, update_frame will change
nothing.

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

Careful with drawing conclusions from the call order alone.  The fact
that redisplay_internal was called doesn't mean it actually decided to
redisplay a specific window, or any window.  The fact that
update_frame was called doesn't necessarily mean that anything at all
was written to the glass.  These functions have a lot of optimizations
in them, and try to avoid doing stuff if they think it isn't
necessary.  You need to trace into the functions' guts to see if they
actually update anything.  Especially update_frame, which tries very
hard to avoid writing to the glass, if it thinks the desired and the
current contents are the same.  That function is the last line of
defense against redisplaying the same stuff over and over again.