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

[Eli Zaretskii]

> From: Robert Weiner <address@hidden>
> Date: Sat, 16 Dec 2017 13:57:34 -0500
> Cc: Alan Third <address@hidden>, emacs-devel <address@hidden>
> 
>  > ​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;
> 
> ​Only one frame is visible on a tty at a time, so in
> my use case, this would have to be the frame that
> displays the window.  Why is this a problem?

TTY redisplay deals with the entire frame, so it cannot redraw a
single window.

>  ​​another is a case where the window was shrunk.
> 
> ​Why can a shrunk window not be displayed within the
> topmost frame?  You are giving examples without explaining
> why they conflict with the desired goal?

I gave examples that explain why Emacs cannot be in general told to
redraw a single window.  Maybe I misunderstood, but I thought this is
what you were trying to accomplish ("display the latest contents of
this window").

> ​So you are saying Emacs provides no way for the programmer
> to ensure that a window is wholly displayed on screen and
> fully updated even when Emacs is the only application in use?

Not if you want to tell Emacs to display _only_ one window.  The
display engine has its own logic that decides what needs to be
redrawn, and Lisp programs should not interfere with those decisions.
That is why we don't provide APIs to achieve that.  Needless to say,
the decisions of the display engine are required to be correct,
i.e. the redrawn display must always reflect the contents of the
shown buffers and their associated Lisp data (properties, overlays,
etc.) as they were found when redisplay was entered.  Any disparity
between the two is a display bug.

> Under what window managers is Emacs unable to raise
> a frame or set input focus reliably?

As Stefan already mentioned, focus policies are very different, and
some of them are affected by user customizations outside of Emacs.
I'm not an expert on window managers to call out specific ones, but
they are all on X, AFAIR.

> I had just dealt with many multi-frame scenarios
> before and never had to call redisplay directly so it seemed
> odd that I had to now.

That's because normally, you don't need to.  Having to display changes
during the command's execution is a rare use case.