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

[Robert Weiner]

On Sat, Dec 16, 2017 at 9:39 AM, Eli Zaretskii <address@hidden> wrote:

> From: Robert Weiner <address@hidden>
> Date: Sat, 16 Dec 2017 08:41:05 -0500
> Cc: Alan Third <address@hidden>, emacs-devel <address@hidden>
>
>  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

​​