help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: closing emacsclient always focuses another emacs window


From: Michael Heerdegen
Subject: Re: closing emacsclient always focuses another emacs window
Date: Mon, 10 Mar 2014 20:40:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]