Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen <michael_heerdegen@web.de>]

Eli Zaretskii <eliz@gnu.org> writes:

> > From: Michael Heerdegen <michael_heerdegen@web.de>
> > Cc: Eli Zaretskii <eliz@gnu.org>
> > Date: Mon, 10 Mar 2014 05:30:42 +0100
> > 
> > It seems that (selected-frame) is intended to "mean" the frame focused
> > when we hit C-x #.  But note that evaluating the argument (server-done)
> > has the side effect of deleting that frame.  Under the right
> > circumstances, the selected frame now can be any frame, including the
> > other emacsclient frame.  In this case, `next-buffer' will be set and
> > the newly selected frame will be focused by the recursive call of
> > `server-switch-buffer'.
>
> AFAIK, which frame becomes selected in this situation is determined by
> the window manager.

I don't think that's what's happening.

This is what is evaluated:

    (apply 'server-switch-buffer (server-done))

After `server-done' is evaluated, the client (e.g. the xterm) always has
input focus.  The fact that

    (advice-add
     'server-switch-buffer :around
     (lambda (f &rest args)
       (when (car args) (apply f args))))

fixes the problem for the OP shows that this is also the case for him.

Note: while (server-done) is evaluated, `server-delete-client' calls
`delete-frame', which implicitly selects another Emacs frame.

Ok, after evaluating (server-done) now we have a different Emacs frame
selected, the server frame was deleted, and xterm has focus.

Now, `server-switch-buffer' is evaluated (without any Emacs frame having
input focus), and, depending on the current selected frame,
`select-frame-set-input-focus'es it as I explained.

So, the issue is completely independent from any window manager.


Regards,

Michael.