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 10:06:10 -0500
> Cc: Alan Third <alan@idiocy.org>, emacs-devel <emacs-devel@gnu.org>
> 
>  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".

That cannot be done in general, because redisplaying a window could
very well affect other windows.  One example of that is TTY frame
display; another is a case where the window was shrunk.  And there are
other, more subtle use cases.

In general, Lisp programs shouldn't dictate the display engine what to
do or not to do, because they can easily make mistakes, being unaware
of all the subtleties.  Instead, it should be the job of the display
engine to determine what and when to redraw, and Lisp can at most
provide hints.

> I don't think Elisp programmers should have to
> master the intricacies of windows, frames, the redisplay engine,
> and window managers to do that.

They don't.  But note that your code attempted to do just that, at
least indirectly.

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

The problem is, many popular WMs do ignore our hints.  So reliable
behavior cannot be built on top of this flaky basis.

> Take raise-frame for example.  Should we not expect
> this to make the given frame the topmost?  The doc string says we
> should.

Martin will tell, but I personally am not sure we can rely on that,
the doc string notwithstanding.

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

But the doc strings need to provide information for much more complex
code as well, not just for simple codes.

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

And what's wrong with that?  You don't need more than one way, as long
as it works.

(There's also redraw-display, but that's hardly suitable for Lisp
programs.)

>  ​​I did, and still couldn't understand the intent.  I still don't, FWIW.
> 
> ​Have I explained it well enough to you now?

Not really, not in detail.  Does that matter?