On Sat, Dec 16, 2017 at 9:39 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Robert Weiner <rsw@gnu.org>
> > Date: Sat, 16 Dec 2017 08:41:05 -0500
> > Cc: Alan Third <alan@idiocy.org>, emacs-devel <emacs-devel@gnu.org>
> >
> >  What do you mean by "displayed temporarily"?  As long as the current
> >  command runs, Emacs will not enter redisplay; an explicit call to
> >  'redisplay' is the only exception to that rule.  So it sounds like
> >  ​​what you describe is Emacs working as designed.
> >
> > ​​​By displayed temporarily, I mean that new frame f2 and old
> > frame f1 largely overlap one another and I want f2 to appear
> > above f1 for a given delay, like half a second and then f1
> > to be raised atop it.​
>
> Then IMO sit-for is not your friend: if input arrives soon enough,
> redisplay will not be called.  And if you happen to have
> redisplay-dont-pause set to nil, even if redisplay _is_ called, it
> might do nothing when sit-for calls it.
>

​Ok, that is an example of why I am advocating for a potentially
new function that let's a programmer say "display the latest
contents of this window with no other Emacs window or frame
obscuring it".  I don't think Elisp programmers should have to
master the intricacies of windows, frames, the redisplay engine,
and window managers to do that.  Does anyone?

​​
>
> ​​
> On top of that, when and how a new frame appears on display is not
> ​​
> only up to Emacs: the WM has a lot to do with that.
>

​Yes, but Emacs sends commands to the WM.  Now if the WM ignores
those commands not much can be done but I think we are interested
in the context where the WM responds as expected to the command
and Emacs either gets a response or can poll to see if the WM state
has changed.  Take raise-frame for example.  Should we not expect
this to make the given frame the topmost?  The doc string says we
should.

​​
>
> ​​
> > I should have noted that I first tried force-window-update (doc string
> ​​
> > says it marks the given window to be redisplayed the next time redisplay
> ​​
> > runs) followed by a sit-for (doc string says it runs redisplay
> unconditionally
> ​​
> > until at least until any further input or timer expiration).  That
> combination
> ​​
> > did not work either.  Only the explicit call to redisplay worked.  This
> seems
> ​​
> > to conflict with the doc strings to me.
> ​​
>
> ​​
> The doc strings try very hard to tell the story completely and
> ​​
> accurately, but it isn't easy, because the underlying behavior is
> ​​
> extremely complex, and needs to cater to some very different use
> ​​
> cases.
>

​I'm mainly asking that obvious gotchas like those demonstrated
by my sample code be mentioned in doc strings, not a deep dive
into all special case technicalities.

​​
>
> ​​
> Here's a rule of thumb I'd advise to anyone who tries to produce such
> ​​
> "temporary" displays: it doesn't work with Emacs, at least not naively
> ​​
> so, so my advice is to try finding other solutions.


​Ok, I'm open and looking for input.  Again, the use case is the
idea of throwing a buffer to a new frame where you want the selected
frame with input focus and its selected window PRIOR to the throw to be
the same after the throw command but you need to show that the buffer has
been thrown to the new frame and the new and the old frame largely overlap.

After using the throw command, the user may soon choose to switch frames
and work with the frame of the thrown buffer, so the frame must still exist
after the throw command finishes.

​
>   Using sit-for,
> ​​
> ​​
> ​​
> ​​
> ​​
> ​​
>
> ​​
> especially in a multi-frame environment with mouse involved is
> ​​
> extremely fragile for these purposes due to non-keyboard events
> ​​
> involved that you cannot predict in advance.
>

​Ok.
​

> ​​
>
> ​​
> Calling 'redisplay' with last argument non-nil is the only way to
> ​​
> actually ensure redisplay, so if you must, use only that.
>

​It sounds like that is the only way since I need to see the current
contents
of the new frame's only window.
​

> ​​
> force-window-update
> ​​
> is useless if redisplay doesn't happen, because it
> ​​
> just sets an advisory
> ​​
> flag for the display engine to consider.
>

​I understand that.
​

> ​​
>
> ​​
> > If you look at the fu
> ​​
> nctions I have
> ​​
> > enclosed, you will s
> ​​
> ee the behavior I am trying to produce.
> ​​
>
> ​​
> I did, and still couldn't understand the intent.  I still don't, FWIW.
>

​Have I explained it well enough to you now?

Thanks,

Bob
​​