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

[Pip Cet <pipcet@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 7654 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 10684 bytes --]