On Wed, Dec 13, 2017 at 3:50 AM, martin rudalics 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