GNU bug report logs - #21333
25.0.50; window-size-change-functions not called after mini-window resize

Previous Next

Full log

Message #100 received at 21333 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 21333 <at> debbugs.gnu.org
Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after
 mini-window resize
Date: Thu, 27 Aug 2015 16:35:44 +0000

[Message part 1 (text/plain, inline)]

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

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

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.