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

[Pip Cet]

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

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

I'm sorry, I totally misread that, then. I think of redisplay cycles as beginning when redisplay() is called and ending when it returns, so in my terminology the "next" redisplay cycle is the one that will happen after control briefly (or not so briefly, see below) returns to the command loop and redisplay() is called again. I don't insist on my terminology, but I don't understand what yours is.

I understood "next redisplay cycle" to refer to the redisplay cycle for which redisplay() has not yet been called, not the one for which redisplay() has already been called.

 

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

Except when they're not, I've just seen this backtrace:

#0  grow_mini_window (w=0x1265ef0, delta=210, pixelwise=true) at window.c:4488
#1  0x0000000000452c01 in resize_mini_window (w=0x1265ef0, exact_p=true) at xdisp.c:10833
#2  0x0000000000426fb9 in do_switch_frame (frame=54632789, track=1, for_deletion=0, norecord=43920) at frame.c:1163
#3  0x000000000042718d in Fselect_frame (frame=54632789, norecord=43920) at frame.c:1225
#4  0x0000000000496566 in select_window (window=54633277, norecord=43920, inhibit_point_swap=false) at window.c:499
#5  0x00000000004967de in Fselect_window (window=54633277, norecord=43920) at window.c:575
#6  0x0000000000453fe7 in x_consider_frame_title (frame=54632789) at xdisp.c:11487
#7  0x0000000000454437 in prepare_menu_bars () at xdisp.c:11595

That's calling resize_mini_window *between* pre-redisplay-function and window-size-change-functions. I had not thought of that possibility. This was triggered by C-x C-e in an elisp buffer after "(read-from-minibuffer longstring)".

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.

But here you're using "next redisplay cycle" to mean the one that has not been started (redisplay() hasn't been called yet), not the one we're currently in.

 

I had assumed your message referred to the state of Emacs as of HEAD, not with my proposed changes included.

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

Because the next call to redisplay() might not be until five seconds later.

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

That wasn't clear to me. If you're asking "will you shut up already if the changes you've already proposed go in", the answer is yes.

So, in the hopes of finally clarifying matters:

I want two things.
Wish #1: a way of knowing "when" windows are resized or moved, even temporarily. Whether that "when" is "just before" or "just after" doesn't really matter, but it should be one of those.

Wish #2: a way of knowing, in advance, that a window is going to be resized or moved, even temporarily, before any of that hits the X server. That would eliminate the (small) window left by #1 when the X server has been updated but redisplay hasn't been called again.

Wish #1, assuming something like my proposed changes go in and this bug is closed, has been granted; there's a race condition, but I might just have to live with that.

Wish #2 eliminates the race condition.

>     , 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 one I call "the current cycle"?

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.

That's not what I seeing running x_sync manually. I'm still grateful for the warning, though.

 

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

Thanks for the warning. I verified with x_sync that the changes had been written to the glass.

I think we agree on what's happening:

1. user input

2. redisplay called

3. prepare_menu_bars called, calls hooks. Hooks think nothing has changed.

4. grow_mini_window called, calculates new window size

5. update_frame is called, writes the new, enlarged mini-window to the glass

6. control returns to command loop

7. redisplay is called again

8. prepare_menu_bars called, calls hooks. Hooks notice mini-window has resized.

Right?

But there's no guarantee that there won't be intermediate commands executed between steps 6 and 7. In fact (progn (message "long message") (sleep 10.0)) will make step 8 happen ten seconds after the changed sizes have been written to the glass.

Wish #2 would mean swapping steps 3 and 4.

Thanks again, particularly for the warning about update_frame not doing anything,

Pip