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

[Robert Weiner <rsw@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]

On Wed, Dec 13, 2017 at 3:50 AM, martin rudalics <rudalics@gmx.at> wrote:

> > Is there something wrong in the test function or is there a problem in
> > select-frame-set-input-focus?
>
> Even if you get a thing like this work on your system, there will be
> always another platform where it fails.


Can you explain what the problem is and why you think it is unsolvable?
In the prior example with raise-frame and lower-frame, we see there is
no problem combining the two of these but once (next-frame) is added
the combination of the two does not work.  Why?  Why would you expect
that to be the case?  Why is it not a bug?


  Note the remark in xfns.c:
>
>    In an ideal world, XSetInputFocus should generally be avoided so
>    that applications don't interfere with the window manager's focus
>    policy.  But I think it's okay to use when it's clearly done
>    following a user-command.


​Better to explain sequences of Elisp functions considered acceptable and
those that are not with regard to input focus handling​ and frame stacking.

Bob

[-- Attachment #2: Type: text/html, Size: 2671 bytes --]