Re: select-frame-set-input-focus fails to raise the frame

[Eli Zaretskii <eliz@gnu.org>]

> 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.

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.

> 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.

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.  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.

Calling 'redisplay' with last argument non-nil is the only way to
actually ensure redisplay, so if you must, use only that.
force-window-update is useless if redisplay doesn't happen, because it
just sets an advisory flag for the display engine to consider.

> If you look at the functions I have
> enclosed, you will see the behavior I am trying to produce.

I did, and still couldn't understand the intent.  I still don't, FWIW.