On Thu, Aug 27, 2015 at 3:25 PM, Eli Zaretskii wrote: > > Date: Thu, 27 Aug 2015 09:59:04 +0200 > > From: martin rudalics > > CC: Eli Zaretskii , 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).