> Date: Thu, 27 Aug 2015 20:49:17 +0000
> From: Pip Cet <pipcet@gmail.com>
> Cc: rudalics@gmx.at, 21333@debbugs.gnu.org
> 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.
That's my interpretation as well.
We
keep saying the same things about the higher levels, and for me it's
clear that our argument is about lower-level details, not about the
high-level overall picture.
But you for some reason think we disagree
on that higher level.
Upon re-reading the thread, it's possible that the misunderstanding is
due to the following factors:
. it's not always clear whether we are talking about what would
happen _after_ resize_mini_window is changed to raise the frame's
"windows changed" flag, or about the current code where it doesn't;
. both window-size-change-functions and pre-redisplay-function is
being discussed, although it should be clear their purpose is
different,
and in particular pre-redisplay-function cannot be moved
from where it currently lives, at least not significantly: it must
run _before_ the bulk of the redisplay code runs, or else it will
fail to fulfill its contract
. you introduce issues into the discussion that are not directly
related to it, which just muddies the waters, for example:
> 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.
No, I mean the next one.
> I had assumed your message referred to the state of Emacs as of HEAD, not with
> my proposed changes included.
It was.
> 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.
This wish needs to be described in more detail. Resizing of a window
is done in several distinct steps:
. some function (resize_mini_window, if we are talking about the
mini-window) decides whether a window should be resized, and if so,
computes its start position;
. redisplay_window, called by redisplay_internal, computes the
"desired" contents of the window on screen;
. update_window, called by update_frame, actually delivers the needed
changes to the glass
I hope it is clear that, depending on what exactly the hook function
wants to do with the info about resizing, it could or should be called
in different parts of the code, which are involved in these steps.
> Wish #2: ....
In addition, it is not clear whether your hook will care if the window
actually didn't change at all.
Also, you never actually explained, AFAIR, why it is so important for
you to be called "just before the change hits the X server".
And finally, I hope you will agree now that pre-redisplay-function is
not the right vehicle for these 2 wishes, because your wishes cannot
be granted before redisplay did most of its job regarding the window
in question.
> 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.
Do you still think it has been granted?
At the very best, you will be
able to obtain part of the information about the window being resized;
the rest of it, which redisplay still needs to figure out, will not
yet be available. For example, if the window being resized is the
mini-window, the buffer position where the window above the
mini-window ends will not yet be known.
> > 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"?
I meant the one we both call "the next".
On further thought, it's
possible that the current cycle will do that, at least in some
situations.
> 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 don't understand what that means
When redisplay decides nothing needs to be recomputed, the current and
the desired contents will be identical.
> 1. user input
> 2. redisplay called
That is inaccurate.
Emacs returns to the
main loop after processing some command, which could be triggered by
user input, or by input from a subprocess, or by some timer that
became ripe, or by input from D-bus, or from any number of additional
input sources.
> 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.