closing emacsclient always focuses another emacs window

closing emacsclient always focuses another emacs window

[trygve.flathen]

I edit files from my terminal with an alias doing
  emacsclient -c file &
When I later close the window with C-#, focus will always be given to another emacs window, even across my virtual desktops.

How can I make focus return to the terminal (or whatever had focus just before) when I close the emacsclient window?

Searching for this problem is hard since it is vastly outnumbered by problems regarding focus on opening the client instead of closing. I found https://bugs.kde.org/show_bug.cgi?id=187718, but that discussion focuses (no pun intended) on kde.

-Trygve

Re: closing emacsclient always focuses another emacs window

[trygve.flathen]

GNU Emacs 24.3.1
Linux Mint 16 Petra, Cinnamon 64-bit

Re: closing emacsclient always focuses another emacs window

[Gregor Zattler]

Hi Trygve,
* trygve.flathen@gmail.com <trygve.flathen@gmail.com> [06. Mar. 2014]:
> I edit files from my terminal with an alias doing
>   emacsclient -c file &
> When I later close the window with C-#, focus will always be given to another emacs window, even across my virtual desktops.
> 
> How can I make focus return to the terminal (or whatever had focus just before) when I close the emacsclient window?
> 
> Searching for this problem is hard since it is vastly outnumbered by problems regarding focus on opening the client instead of closing. I found https://bugs.kde.org/show_bug.cgi?id=187718, but that discussion focuses (no pun intended) on kde.


I had the very same problem.  If focus-follows-mouse is non-nil
on your system please have a look at
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7553

Perhaps setting focus-follows-mouse to nil helps.


Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: closing emacsclient always focuses another emacs window

[lee]

Gregor Zattler <telegraph@gmx.net> writes:

> Hi Trygve,
> * trygve.flathen@gmail.com <trygve.flathen@gmail.com> [06. Mar. 2014]:
>> I edit files from my terminal with an alias doing emacsclient -c file
>>   & When I later close the window with C-#, focus will always be
>>   given to another emacs window, even across my virtual desktops.
>> 
>> How can I make focus return to the terminal (or whatever had focus
>> just before) when I close the emacsclient window?
>> 
>> Searching for this problem is hard since it is vastly outnumbered by
>> problems regarding focus on opening the client instead of closing. I
>> found https://bugs.kde.org/show_bug.cgi?id=187718, but that
>> discussion focuses (no pun intended) on kde.
>
>
> I had the very same problem.  If focus-follows-mouse is non-nil
> on your system please have a look at
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7553

FWIW, I´m using fvwm with FocusFollowsMouse and don´t have this
problem.  Fvwm strictly focuses the window which happens to be under the
mouse pointer as it should.

The problem is very likely with the WM of kde having a strange idea
about what FocusFollowsMouse means.

> Perhaps setting focus-follows-mouse to nil helps.

FocusFollowsMouse is one of the required basic features a WM must have
before I´d consider it as useable.  Using fvwm instead of the WM kde
comes with might be a better solution.


-- 
Knowledge is volatile and fluid.  Software is power.

Re: closing emacsclient always focuses another emacs window

[Gregor Zattler]

Hi lee,
* lee <lee@yun.yagibdah.de> [07. Mar. 2014]:
> Gregor Zattler <telegraph@gmx.net> writes:
>> I had the very same problem.  If focus-follows-mouse is non-nil
>> on your system please have a look at
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7553
> 
> FWIW, I´m using fvwm with FocusFollowsMouse and don´t have this
> problem.  Fvwm strictly focuses the window which happens to be under the
> mouse pointer as it should.

This is not a WM setting but a misnomed setting of emacs: When 
focus-follows-mouse is non-nil, emacs moves the mouse to another
emacs frame when one is closed.

> The problem is very likely with the WM of kde having a strange idea
> about what FocusFollowsMouse means.
> 
>> Perhaps setting focus-follows-mouse to nil helps.
> 
> FocusFollowsMouse is one of the required basic features a WM must have
> before I´d consider it as useable.  Using fvwm instead of the WM kde
> comes with might be a better solution.

As you like it.  But in context of the bug the problem is with
emacs not with the WM (can be seen even without a WM).

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: closing emacsclient always focuses another emacs window

[lee]

Gregor Zattler <telegraph@gmx.net> writes:

> Hi lee,
> * lee <lee@yun.yagibdah.de> [07. Mar. 2014]:
>> Gregor Zattler <telegraph@gmx.net> writes:
>>> I had the very same problem.  If focus-follows-mouse is non-nil
>>> on your system please have a look at
>>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7553
>> 
>> FWIW, I´m using fvwm with FocusFollowsMouse and don´t have this
>> problem.  Fvwm strictly focuses the window which happens to be under the
>> mouse pointer as it should.
>
> This is not a WM setting but a misnomed setting of emacs: When 
> focus-follows-mouse is non-nil, emacs moves the mouse to another
> emacs frame when one is closed.

Oh, sorry, I didn´t realise that emacs has a variable like that.  It´s
value is nil here ...


-- 
Knowledge is volatile and fluid.  Software is power.

Re: closing emacsclient always focuses another emacs window

[trygve.flathen]

kl. 23:11:39 UTC+1 torsdag 6. mars 2014 skrev Gregor Zattler følgende:
> If focus-follows-mouse is non-nil
> on your system please have a look at
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7553

focus-follows-mouse is already nil on my system. I do get the behaviour discussed in the bugreport if I set it to non-nil.

At the moment I am not using a focus-follows-mouse focus model in my WM (cinnamon is a gnome-based WM btw). On this system I would prefer to continue using Alt-tab.

Setting my WM to focus-follows-mouse does not alter the unwanted behavior either. Another emacs window still gets the focus after C-x #, even raising one of them if none is visible or switching to another virtual desktop.

>  -... --- .-. . -.. ..--.. ...-.-

-... --- .-. . -.. / .--. . --- .--. .-.. . / -.. --- -. .----. - / -.. . ... . .-. ...- . / ..-. .-. . . / - .. -- .

-Trygve

Re: closing emacsclient always focuses another emacs window

[Gregor Zattler]

Hi Trygve,
* trygve.flathen@gmail.com <trygve.flathen@gmail.com> [07. Mar. 2014]:
> kl. 23:11:39 UTC+1 torsdag 6. mars 2014 skrev Gregor Zattler følgende:
>> If focus-follows-mouse is non-nil
>> on your system please have a look at
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7553
> 
> focus-follows-mouse is already nil on my system. I do get the
> behaviour discussed in the bugreport if I set it to non-nil. 

Hmh.  Then I'm lost.  Does the mouse move when this focus change
happens?

Ciao; Gregor

Re: closing emacsclient always focuses another emacs window

[trygve.flathen]

kl. 19:31:12 UTC+1 fredag 7. mars 2014 skrev Gregor Zattler følgende:
> Hmh.  Then I'm lost.  Does the mouse move when this focus change
> happens?

Nope, not when focus-follows-mouse is nil.

-Trygve

Re: closing emacsclient always focuses another emacs window

[Eli Zaretskii]

> Date: Sat, 8 Mar 2014 05:18:55 -0800 (PST)
> From: trygve.flathen@gmail.com
> 
> kl. 19:31:12 UTC+1 fredag 7. mars 2014 skrev Gregor Zattler følgende:
> > Hmh.  Then I'm lost.  Does the mouse move when this focus change
> > happens?
> 
> Nope, not when focus-follows-mouse is nil.

Can you please clarify what focus change you'd like to avoid, exactly?
I couldn't understand that from your original message.  When a frame
created by emacsclient is deleted, that frame no longer exists, so
it's not clear to me how could Emacs _not_ switch the focus to some
other frame.

I'm sure you realize this, so I'm pretty confident there's some
misunderstanding on my part.

Re: closing emacsclient always focuses another emacs window

[Yuri Khan]

On Sat, Mar 8, 2014 at 8:26 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Can you please clarify what focus change you'd like to avoid, exactly?
> I couldn't understand that from your original message.  When a frame
> created by emacsclient is deleted, that frame no longer exists, so
> it's not clear to me how could Emacs _not_ switch the focus to some
> other frame.

Emacs could leave it to the window manager to decide which other
window to focus. Which it in fact does on my machine (Xubuntu Saucy;
GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.2) of
2013-07-27 on roseapple, modified by Debian; i3 window manager).
Apparently, not on Trygve’s machine.

Re: closing emacsclient always focuses another emacs window

[Eli Zaretskii]

> Date: Sat, 8 Mar 2014 21:30:41 +0700
> From: Yuri Khan <yuri.v.khan@gmail.com>
> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> 
> On Sat, Mar 8, 2014 at 8:26 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Can you please clarify what focus change you'd like to avoid, exactly?
> > I couldn't understand that from your original message.  When a frame
> > created by emacsclient is deleted, that frame no longer exists, so
> > it's not clear to me how could Emacs _not_ switch the focus to some
> > other frame.
> 
> Emacs could leave it to the window manager to decide which other
> window to focus. Which it in fact does on my machine (Xubuntu Saucy;
> GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.2) of
> 2013-07-27 on roseapple, modified by Debian; i3 window manager).

How would that help?  And what is the problem in the first place,
anyway?  Why does it matter who or what decides which other frame to
give focus to?

Re: closing emacsclient always focuses another emacs window

[Dan Espen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 8 Mar 2014 21:30:41 +0700
>> From: Yuri Khan <yuri.v.khan@gmail.com>
>> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
>> 
>> On Sat, Mar 8, 2014 at 8:26 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> > Can you please clarify what focus change you'd like to avoid, exactly?
>> > I couldn't understand that from your original message.  When a frame
>> > created by emacsclient is deleted, that frame no longer exists, so
>> > it's not clear to me how could Emacs _not_ switch the focus to some
>> > other frame.
>> 
>> Emacs could leave it to the window manager to decide which other
>> window to focus. Which it in fact does on my machine (Xubuntu Saucy;
>> GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.2) of
>> 2013-07-27 on roseapple, modified by Debian; i3 window manager).
>
> How would that help?  And what is the problem in the first place,
> anyway?  Why does it matter who or what decides which other frame to
> give focus to?

Surprised you would take that position.
Focus management is best controlled by the WM.
Fvwm, for example, has a lot of focus knobs to twist.
Emacs is just one of the windows on a users screen.
A user is looking for uniform control of all the windows.

-- 
Dan Espen

Re: closing emacsclient always focuses another emacs window

[trygve.flathen]

kl. 14:26:37 UTC+1 lørdag 8. mars 2014 skrev Eli Zaretskii følgende:
> Can you please clarify what focus change you'd like to avoid, exactly?
> I couldn't understand that from your original message.  When a frame
> created by emacsclient is deleted, that frame no longer exists, so
> it's not clear to me how could Emacs _not_ switch the focus to some
> other frame.

That's right, the problem is _which_ other frame.

Example:
- I start with two windows: a terminal and an emacsclient for some file named foo that I started yesterday. The emacsclient is minimized and the terminal has focus.
- I do "emacsclient -c /tmp/bar". A second emacsclient window is created and focused.
- I do my work, save the bar file, and do C-x #. The bar window disappears.

What I now want: terminal gets the focus back.
What actually happens: The foo emacsclient is raised and gets focus.

In fact, another emacs window is always focused when I close an emacsclient, regardless of what the focus stack was when I closed it.

Usually when a window is closed, focus is returned to whatever had focus immediately before the now closed window got focus.

Hope that cleared it up a bit.

-Trygve

Re: closing emacsclient always focuses another emacs window

[Eli Zaretskii]

> From: Dan Espen <despen@verizon.net>
> Date: Sat, 08 Mar 2014 10:53:31 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Emacs could leave it to the window manager to decide which other
> >> window to focus. Which it in fact does on my machine (Xubuntu Saucy;
> >> GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.2) of
> >> 2013-07-27 on roseapple, modified by Debian; i3 window manager).
> >
> > How would that help?  And what is the problem in the first place,
> > anyway?  Why does it matter who or what decides which other frame to
> > give focus to?
> 
> Surprised you would take that position.

What you perceive as my "position" is nothing more than an attempt to
understand the OP's complaint.  Until I do understand that, I cannot
possibly have any position, can I?

Re: closing emacsclient always focuses another emacs window

[Eli Zaretskii]

> Date: Sat, 8 Mar 2014 07:58:05 -0800 (PST)
> From: trygve.flathen@gmail.com
> 
> kl. 14:26:37 UTC+1 lørdag 8. mars 2014 skrev Eli Zaretskii følgende:
> > Can you please clarify what focus change you'd like to avoid, exactly?
> > I couldn't understand that from your original message.  When a frame
> > created by emacsclient is deleted, that frame no longer exists, so
> > it's not clear to me how could Emacs _not_ switch the focus to some
> > other frame.
> 
> That's right, the problem is _which_ other frame.
> 
> Example:
> - I start with two windows: a terminal and an emacsclient for some file named foo that I started yesterday. The emacsclient is minimized and the terminal has focus.
> - I do "emacsclient -c /tmp/bar". A second emacsclient window is created and focused.
> - I do my work, save the bar file, and do C-x #. The bar window disappears.
> 
> What I now want: terminal gets the focus back.
> What actually happens: The foo emacsclient is raised and gets focus.

Thanks, I understand the issue now.

But I cannot reproduce what you describe on my machine: what I get is
the behavior you want, i.e. the Emacs frame created by emacsclient
disappears from the display, and the terminal window from which I
invoked that emacsclient gets back the focus.

So perhaps this is something related to your window manager?  That's
assuming that you see the same behavior when you start "emacs -Q",
then start the server there, and finally do what you describe above.
If in "emacs -Q" the problem doesn't happen, then look in your
~/.emacs for the culprit.  If, OTOH, "emacs -Q" exhibits the same
behavior, perhaps sharing your window manager and its customizations
will reveal the reason(s) for the behavior you observe.

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> How would that help?  And what is the problem in the first place,
> anyway?  Why does it matter who or what decides which other frame to
> give focus to?

As far as I understood, the OP wants that the X window that had focus
before emacsclient was called gets focus back, and not any Emacs frame.
I.e., Emacs would "give up" its focus for the benefit of the last
focused X window.  Without killing Emacs, of course.

I don't think that this is possible, but I agree that it could be a
desirable behavior.


Regards,

Michael.

Re: closing emacsclient always focuses another emacs window

[Eli Zaretskii]

> Date: Sat, 08 Mar 2014 19:38:36 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> So perhaps this is something related to your window manager?  That's
> assuming that you see the same behavior when you start "emacs -Q",
> then start the server there, and finally do what you describe above.
> If in "emacs -Q" the problem doesn't happen, then look in your
> ~/.emacs for the culprit.  If, OTOH, "emacs -Q" exhibits the same
> behavior, perhaps sharing your window manager and its customizations
> will reveal the reason(s) for the behavior you observe.

Btw, I forgot to ask: which Emacs version is that, and how was it
compiled?  (The values of system-configuration and
system-configuration-options will supply the answer to the latter
part.)

Re: closing emacsclient always focuses another emacs window

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Sat, 08 Mar 2014 18:45:55 +0100
> 
> As far as I understood, the OP wants that the X window that had focus
> before emacsclient was called gets focus back, and not any Emacs frame.
> I.e., Emacs would "give up" its focus for the benefit of the last
> focused X window.  Without killing Emacs, of course.

That's my understanding as well.

> I don't think that this is possible, but I agree that it could be a
> desirable behavior.

As long as Emacs does not forcibly raises one of its other frames (on
my system and with Emacs 23.4, it doesn't), which other window gets
focus is up to the window manager, AFAIU.  FWIW, I see the desired
behavior on my system, so it's not impossible.

Re: closing emacsclient always focuses another emacs window

[trygve.flathen]

kl. 18:45:55 UTC+1 lørdag 8. mars 2014 skrev Michael Heerdegen følgende:
> As far as I understood, the OP wants that the X window that had focus
> before emacsclient was called gets focus back, and not any Emacs frame.

To clarify a possible misunderstanding, It is not necessarily that exact window which had focus when emacsclient was started, I just want whichever window that was focused just before the emacsclient got its focus the last time.

This is how all combinations of linuxen, windowmanagers and emacsen I have tried until now works.

-Trygve

Re: closing emacsclient always focuses another emacs window

[trygve.flathen]

kl. 18:54:14 UTC+1 lørdag 8. mars 2014 skrev Eli Zaretskii følgende:
> Btw, I forgot to ask: which Emacs version is that, and how was it
> compiled?  (The values of system-configuration and
> system-configuration-options will supply the answer to the latter
> part.)

I'm using the default emacs24 from the repositories of Linux Mint 16.
apt-get install emacs24

emacs-version is a variable defined in `C source code'.
Its value is "24.3.1"

system-configuration is a variable defined in `C source code'.
Its value is "x86_64-pc-linux-gnu"

system-configuration-options is a variable defined in `C source code'.
Its value is
" '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3/site-lisp:/usr/share/emacs/site-lisp' '--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes' '--with-x-toolkit=gtk3' '--with-toolkit-scroll-bars' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2'"

-Trygve

Re: closing emacsclient always focuses another emacs window

[trygve.flathen]

kl. 18:38:36 UTC+1 lørdag 8. mars 2014 skrev Eli Zaretskii følgende:
> So perhaps this is something related to your window manager?  That's
> assuming that you see the same behavior when you start "emacs -Q",
> then start the server there, and finally do what you describe above.
> If in "emacs -Q" the problem doesn't happen, then look in your
> ~/.emacs for the culprit.  If, OTOH, "emacs -Q" exhibits the same
> behavior, perhaps sharing your window manager and its customizations
> will reveal the reason(s) for the behavior you observe.

I get the same problematic behaviour when I start emacs with -Q.

I am using Cinnamon (GTK-based) WM (Default WM in Mint16), no particular customizations that I am aware of.

I have previously mostly used various rhel/fedora linux and xemacs.
Since this system (Mint16, gnu emacs) is new to me, I don't know if the problem is with emacs of the WM.

However, I do not see this kind of behaviour with other programs (e.g. firefox), which makes me think it is at least partly to do with emacs/emacsclient.

-Trygve

Re: closing emacsclient always focuses another emacs window

[Eli Zaretskii]

> Date: Sat, 8 Mar 2014 11:06:05 -0800 (PST)
> From: trygve.flathen@gmail.com
> 
> However, I do not see this kind of behaviour with other programs (e.g. firefox), which makes me think it is at least partly to do with emacs/emacsclient.

But the fact that Emacs doesn't raise any frames on my system does
sound like an evidence against that.

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> As long as Emacs does not forcibly raises one of its other frames (on
> my system and with Emacs 23.4, it doesn't), which other window gets
> focus is up to the window manager, AFAIU.  FWIW, I see the desired
> behavior on my system, so it's not impossible.

Indeed.  I tested emacsclient without -c.  When I use -c, I too see the
desired behavior, even when multiple clients are involved.


Regards,

Michael.

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Indeed.  I tested emacsclient without -c.  When I use -c, I too see the
> desired behavior, even when multiple clients are involved.

But wait, it depends on the way the server had been started.

When I first start emacs (emacs -Q), and do M-x start-server, and follow
the recipe, I get the desired behavior.

OTOH, when I start up with emacs -Q --daemon, and follow the recipe, I
see what trygve.flathen sees.

Michael.

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> OTOH, when I start up with emacs -Q --daemon, and follow the recipe, I
> see what trygve.flathen sees.

For that second case, I tried debug-on-entry
`select-frame-set-input-focus' before hitting C-x #.  Something very
interesting happened: The focus was given back to my xterm, and a
debugger in Emacs popped up with the following content:

Debugger entered--entering a function:
* select-frame-set-input-focus(#<frame emacs@drachen 0x12d3ef0>)
  server-switch-buffer(#<buffer test.txt> t)
  server-switch-buffer(nil t)
  apply(server-switch-buffer (nil t))
  server-edit(nil)
  call-interactively(server-edit nil nil)
  command-execute(server-edit)

And this `select-frame-set-input-focus' obviously moves focus back to
Emacs.  Dunno if it's intended.


Regards,

Michael.

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

trygve.flathen@gmail.com writes:

> This is how all combinations of linuxen, windowmanagers and emacsen I
> have tried until now works.

How do you start the server?

Does evaluating the following change the behavior for you?

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


Regards,

Michael.

Re: closing emacsclient always focuses another emacs window

[trygve.flathen]

kl. 01:44:00 UTC+1 søndag 9. mars 2014 skrev Michael Heerdegen følgende:
> How do you start the server?

I usually start emacs just with "emacs&", and I have (server-start) in init.el.

> When I first start emacs (emacs -Q), and do M-x start-server, and follow 
> the recipe, I get the desired behavior. 
> 
> OTOH, when I start up with emacs -Q --daemon, and follow the recipe, I 
> see what trygve.flathen sees. 

Both of these methods give me the same undesired behaviour, with or without server-start in init.el.

> Does evaluating the following change the behavior for you?

Seems like I am missing something:

Debugger entered--Lisp error: (void-function advice-add)
  (advice-add (quote server-switch-buffer) :around (lambda (f &rest args) (when (car args) (apply f args))))
  eval((advice-add (quote server-switch-buffer) :around (lambda (f &rest args) (when (car args) (apply f args)))) nil)
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp nil nil)

-Trygve

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

trygve.flathen@gmail.com writes:

> > When I first start emacs (emacs -Q), and do M-x start-server, and
> > follow
> > the recipe, I get the desired behavior. 
> > 
> > OTOH, when I start up with emacs -Q --daemon, and follow the recipe, I 
> > see what trygve.flathen sees. 
>
> Both of these methods give me the same undesired behaviour, with or
> without server-start in init.el.

Interesting.  And you used the -c flag for emacsclient in both cases,
yes?

> > Does evaluating the following change the behavior for you?
>
> Seems like I am missing something:
>
> Debugger entered--Lisp error: (void-function advice-add)
>   (advice-add (quote server-switch-buffer) :around (lambda (f &rest
> args) (when (car args) (apply f args))))
>   eval((advice-add (quote server-switch-buffer) :around (lambda (f
> &rest args) (when (car args) (apply f args)))) nil)
>   eval-last-sexp-1(nil)
>   eval-last-sexp(nil)
>   call-interactively(eval-last-sexp nil nil)

Ok, let's try with the old advice mechanism:

(defadvice server-switch-buffer (around test activate)
  (when (ad-get-arg 0) ad-do-it))

You can (with a newly started server) also M-x debug-on-entry
select-frame-set-input-focus.  If you get a popping up debugger after
hitting C-x #, please send us the backtrace.


Regards,

Michael.

Re: closing emacsclient always focuses another emacs window

[trygve.flathen]

kl. 19:54:00 UTC+1 søndag 9. mars 2014 skrev Michael Heerdegen følgende:
> Interesting.  And you used the -c flag for emacsclient in both cases,
> yes?

yup.

> Ok, let's try with the old advice mechanism:
> (defadvice server-switch-buffer (around test activate)
>   (when (ad-get-arg 0) ad-do-it))

Yay! That did it. And when I put it in init.el after server-start, all is pure joy.

> You can (with a newly started server) also M-x debug-on-entry
> select-frame-set-input-focus.  If you get a popping up debugger after
> hitting C-x #, please send us the backtrace.

Yep, it popped up. If you still want the backtrace:
http://flathen.net/tmp/trygve-flathen.backtrace
I'd be glad to provide further test info if needed.

Thanks all of you for the help. Don't think I would've come up with that piece of elisp anytime soon without it :-)

-Trygve

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

trygve.flathen@gmail.com writes:

> > (defadvice server-switch-buffer (around test activate)
> >   (when (ad-get-arg 0) ad-do-it))

> Yay! That did it. And when I put it in init.el after server-start, all
> is pure joy.

Great!

Although it's just a workaround of the symptom.  I still don't know why
we at all see a different behavior, and which behavior is intended.

Eli, would you consider the behavior he sees as a bug?  Would it be
worth it to make the behavior configurable?


Regards,

Michael.

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

trygve.flathen@gmail.com writes:

> Yep, it popped up. If you still want the backtrace:
> http://flathen.net/tmp/trygve-flathen.backtrace

That looks like a backtrace from the moment when you invoked
emacsclient, no?  We need a backtrace from the "pathological" point of
time after you hit C-x #.  So, it's better to M-x debug-on-entry just
immediately before this C-x #, so that the debugger doesn't pop up in
other situations before.

And please load server.el (the uncompiled source file) beforehand if you
have it, so that we have no byte code in the backtrace.


Regards,

Michael.

Re: closing emacsclient always focuses another emacs window

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Sun, 09 Mar 2014 22:36:14 +0100
> 
> Although it's just a workaround of the symptom.  I still don't know why
> we at all see a different behavior, and which behavior is intended.
> 
> Eli, would you consider the behavior he sees as a bug?

Not sure, because it doesn't match what we see.  Could be.

> Would it be worth it to make the behavior configurable?

Hard to say, until we understand the reasons.

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Not sure, because it doesn't match what we see.  Could be.

I think I found something which I hope could explain the confusion.

When the OP hits C-x #, this is executed in `server-edit':

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

`server-done' returns a list (nil ...), so this code at the beginning of
`server-switch-buffer' is executed:

(if (null next-buffer)
      (progn
	(let ((rest server-clients))
	  (while (and rest (not next-buffer))
	    (let ((proc (car rest)))
	      ;; Only look at frameless clients, or those in the selected
	      ;; frame.
	      (when (or (not (process-get proc 'frame))
			(eq (process-get proc 'frame) (selected-frame)))
		(setq next-buffer (car (process-get proc 'buffers))))
	      (setq rest (cdr rest)))))
	(and next-buffer (server-switch-buffer next-buffer killed-one))
	(unless (or next-buffer killed-one (window-dedicated-p))
	  ;; (switch-to-buffer (other-buffer))
	  (message "No server buffers remain to edit"))) ...

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'.


Regards,

Michael.

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

Hello again,

I managed to get both behaviors with one server.  For the behavior the
OP sees,

  (when (or (not (process-get proc 'frame))
            (eq (process-get proc 'frame) (selected-frame)))
		(setq next-buffer (car (process-get proc 'buffers))))

(in some iteration) does set next-buffer.  For the behavior the OP
wants, next-buffer is not set.  So this seems to be the part were the
behaviors begin to diverge.

Michael.

Re: closing emacsclient always focuses another emacs window

[Eli Zaretskii]

> 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.

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

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.

Re: closing emacsclient always focuses another emacs window

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Mon, 10 Mar 2014 20:40:32 +0100
> 
> > 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.

I'm sorry, but you lost me.

All I know is that I don't see on my system any Emacs frame being
raised.

Re: closing emacsclient always focuses another emacs window

[Eli Zaretskii]

> Date: Mon, 10 Mar 2014 22:03:45 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: help-gnu-emacs@gnu.org
> 
> > From: Michael Heerdegen <michael_heerdegen@web.de>
> > Date: Mon, 10 Mar 2014 20:40:32 +0100
> > 
> > > 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.
> 
> I'm sorry, but you lost me.
> 
> All I know is that I don't see on my system any Emacs frame being
> raised.

Sorry, hit the wrong key.

What I wanted to say is that Emacs doesn't have any capabilities to
set input focus to a TTY (or xterm) frame.  It can only do that for
GUI frames, and even then not always.

Also, selecting a frame doesn't mean that frame gets focus, even for
GUI frames.  There's always a selected frame in Emacs, but focus might
well belong to another application, so we could have a situation where
none of the Emacs frames has focus.

So I'm not at all sure how all this description of what happens with
selecting a different frame is relevant to the issue at hand, which
(AFAIU) is about Emacs TTY frames or xterm windows that get or don't
get focus after "C-x #".

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Also, selecting a frame doesn't mean that frame gets focus, even for
> GUI frames.  There's always a selected frame in Emacs, but focus might
> well belong to another application, so we could have a situation where
> none of the Emacs frames has focus.

I know that.  But in the problematic case, after the xterm has got
focus, `server-switch-buffer' explicitly sets focus back to the
selected frame:

(when server-raise-frame
      (select-frame-set-input-focus (window-frame)))


I have a recipe that reproduces the problem in 100% of the cases,
and I'm sure that the window manager isn't involved:

1. start xterm
2. emacs -Q
3. M-x server-start
4. Focus the xterm
5. emacsclient -c /path/to/file1 &
   A new emacs frame pops up and has focus
6. close the _other_ Emacs frame (the one showing the *scratch* buffer)
7. Focus the xterm
8. emacsclient -c /path/to/file2 &
   A new emacs frame pops up, showing file2, and has focus.
9. in this frame: C-x #

Now, the other Emacs frame has focus, not the xterm.

It would be very interesting if you could not reproduce this.  It is
IMHO inevitable when I look at the code.

Eli, if you really don't see this behavior, please try to find out which
of the following is not true for you, after hitting C-x # in 9.  These
steps _prove_ that what the OP sees will happen with the above recipe:


- `server-edit' evaluates (apply 'server-switch-buffer (server-done))
  because `server-clients is non-nil

- (server-done) is evaluated.  It deletes the current frame.  xterm gets
  focus.  `server-done' returns a list whose car is nil.  The
  `selected-frame' is now the one showing file1 (it's the only frame
  left), but it doesn't have focus.  But, of course, Emacs continues
  evaluating.

- `server-switch-buffer' is applied to the result of (server-done).  It
  evaluates this:

if (null next-buffer)
      (progn
	(let ((rest server-clients))
	  (while (and rest (not next-buffer))
	    (let ((proc (car rest)))
	      ;; Only look at frameless clients, or those in the selected
	      ;; frame.
	      (when (or (not (process-get proc 'frame))
			(eq (process-get proc 'frame) (selected-frame)))
		(setq next-buffer (car (process-get proc 'buffers))))
	      (setq rest (cdr rest)))))
	(and next-buffer (server-switch-buffer next-buffer killed-one))

next-buffer is set to the buffer associated with file1, and
`server-switch-buffer' is called recursively.

- At the end of the recursive `server-switch-buffer' call, this is
  evaluated:

(when server-raise-frame
      (select-frame-set-input-focus (window-frame)))

which sets input focus to the Emacs frame.


Regards,

Michael.

Re: closing emacsclient always focuses another emacs window

[trygve.flathen]

kl. 03:40:15 UTC+1 mandag 10. mars 2014 skrev Michael Heerdegen følgende:
> That looks like a backtrace from the moment when you invoked
> emacsclient, no?  We need a backtrace from the "pathological" point of
> time after you hit C-x #.  So, it's better to M-x debug-on-entry just
> immediately before this C-x #, so that the debugger doesn't pop up in
> other situations before.

Trying again:

$ emacs
M-x server-start

$ emacsclient -c foo

$ emacsclient -c bar
M-x debug-on-entry RET select-frame-set-input-focus RET
C-x #

At that moment this Backtrace pops up in the foo window:

Debugger entered--entering a function:
* select-frame-set-input-focus(#<frame foo 0x115bc90>)
  server-switch-buffer(#<buffer foo> t)
  server-switch-buffer(nil t)
  apply(server-switch-buffer (nil t))
  server-edit(nil)
  call-interactively(server-edit nil nil)

-Trygve

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

trygve.flathen@gmail.com writes:

> Trying again:
>
> $ emacs
> M-x server-start
>
> $ emacsclient -c foo
>
> $ emacsclient -c bar
> M-x debug-on-entry RET select-frame-set-input-focus RET
> C-x #
>
> At that moment this Backtrace pops up in the foo window:
>
> Debugger entered--entering a function:
> * select-frame-set-input-focus(#<frame foo 0x115bc90>)
>   server-switch-buffer(#<buffer foo> t)
>   server-switch-buffer(nil t)
>   apply(server-switch-buffer (nil t))
>   server-edit(nil)
>   call-interactively(server-edit nil nil)

Thanks.

That's consistent with my analysis I described earlier today, and shows
that it's Emacs that focuses the frame, and not any window manager.


Regards,

Michael.

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

trygve.flathen@gmail.com writes:

> $ emacs
> M-x server-start
>
> $ emacsclient -c foo
>
> $ emacsclient -c bar

BTW, when I do (setq server-raise-frame nil), calling emacsclient with
the -c option still creates and raises and focuses new frames, but the
behavior when hitting C-x # is as you want.

Michael.

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> (when server-raise-frame
>       (select-frame-set-input-focus (window-frame)))

This is also the documented behavior:

  C-x # runs the command server-edit, which is an interactive compiled
  Lisp function in `server.el'.
  
  [...]

  Switch to next server editing buffer [...]
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


  server-raise-frame is a variable defined in `server.el'.
  Its value is t
  
  Documentation:
  If non-nil, raise frame when switching to a buffer.


And setting server-raise-frame to nil fixes the "problem" for me.

IMHO the only problem is the vague name and documentation of the option
`server-raise-frame': I sounds like it would influence the behavior when
emacsclient is invoked, but it is decisive when you hit C-x #.  And it
does not only raise a frame, it also sets input focus.  And it's not
even mentioned in the manual.

BTW, a minor problem is that Emacs tries to delete the only visible
frame if you have only one frame that is associated to a client and you
hit C-x #.

If Eli agrees, I'll file a bug report about this.


Michael.

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> IMHO the only problem is the vague name and documentation of the option
> `server-raise-frame'

No, that can't be all.  Because the behavior depends on the fact which
buffer is coincidentally selected by Emacs when it deletes the frame
after hitting C-x #.  That can't have been the intention of the
author.

Michael.

Re: closing emacsclient always focuses another emacs window

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Tue, 11 Mar 2014 05:25:43 +0100
> 
> Michael Heerdegen <michael_heerdegen@web.de> writes:
> 
> > IMHO the only problem is the vague name and documentation of the option
> > `server-raise-frame'
> 
> No, that can't be all.  Because the behavior depends on the fact which
> buffer is coincidentally selected by Emacs when it deletes the frame
> after hitting C-x #.  That can't have been the intention of the
> author.

Why not?

Anyway, now I'm utterly confused.  First, the OP's description of the
problem included iconified frames -- did you do your testing like he
described?

Second, I'm still unsure whether we are talking about GUI or TTY
frames; in the latter case, I'm sure you will agree that
select-frame-set-input-focus will never give focus to any TTY frame.

Last, but not least, AFAIK the effect of select-frame-set-input-focus
on the GUI frame that gets focus does depend on the window manager to
some extent.

In any case, I suggest to report the full detailed description of the
issue via "M-x report-emacs-bug", and include there suggestions to fix
the doc strings, if you still think they need fixing.

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > From: Michael Heerdegen <michael_heerdegen@web.de>
> > Date: Tue, 11 Mar 2014 05:25:43 +0100
> > 
> > Michael Heerdegen <michael_heerdegen@web.de> writes:
> > 
> > > IMHO the only problem is the vague name and documentation of the
> > > option
> > > `server-raise-frame'
> > 
> > No, that can't be all.  Because the behavior depends on the fact which
> > buffer is coincidentally selected by Emacs when it deletes the frame
> > after hitting C-x #.  That can't have been the intention of the
> > author.
>
> Why not?

Because in one case, Emacs looses input focus, and in another, Emacs
keeps it.  And because the doc of C-x # says that there will always be a
frame raised, which is obviously not the case.

> Anyway, now I'm utterly confused.

Sorry about that.  You seemed to deny that there is a problem.  So I
argued that there is absolutely no clear description in the
documentation of how C-x # should behave, for no case, so it's
impossible to says what behavior is right and what is a bug.  So I
showed that the behavior is not even consistent, and I proved that the
cause of the inconsistent behavior is in the code in server.el.  What
could I do more to show that there _is_ a problem?

> First, the OP's description of the
> problem included iconified frames -- did you do your testing like he
> described?

I tested with gui frames.  And yes, Emacs even raises and focuses
iconified frames.

> Second, I'm still unsure whether we are talking about GUI or TTY
> frames; in the latter case, I'm sure you will agree that
> select-frame-set-input-focus will never give focus to any TTY frame.

I tried with GUI frames.

> Last, but not least, AFAIK the effect of select-frame-set-input-focus
> on the GUI frame that gets focus does depend on the window manager to
> some extent.

In my experiments, this function always in effect raised the argument
frame and set input focus to exactly that frame.  But whether Emacs
calls `select-frame-set-input-focus' after hitting C-x # is not
consistent, so no window manager could have the effect of making the
behavior consistent again.

> In any case, I suggest to report the full detailed description of the
> issue via "M-x report-emacs-bug", and include there suggestions to fix
> the doc strings, if you still think they need fixing.

trygve.flathen, can you please file a bug report (M-x report-emacs-bug)
with your original problem and a recipe?  I'll then step in and add what
I found out and some words about missing documentation.

But if you happen to find out that setting `server-raise-frame' to nil
does what you want, then I suggest that you don't file the report.  In
that case, I'll just report the missing doc and strange behavior.
Thanks.


Regards,

Michael.

Re: closing emacsclient always focuses another emacs window

[trygve.flathen]

kl. 18:23:08 UTC+1 tirsdag 11. mars 2014 skrev Eli Zaretskii følgende:
> Anyway, now I'm utterly confused.  First, the OP's description of the
> problem included iconified frames -- did you do your testing like he
> described?

Sorry if the information was not clear. I have been talking about GUI frames (i.e. X Windows frames). The problem involved any such frames, I mentioned iconified frames or frames on other virtual desktops because that would be very unusual behaviour for a window manager.

-Trygve

Re: closing emacsclient always focuses another emacs window

[trygve.flathen]

kl. 01:31:58 UTC+1 onsdag 12. mars 2014 skrev Michael Heerdegen følgende:
> trygve.flathen, can you please file a bug report (M-x report-emacs-bug)
> with your original problem and a recipe?  I'll then step in and add what
> I found out and some words about missing documentation.
> 
> But if you happen to find out that setting `server-raise-frame' to nil
> does what you want, then I suggest that you don't file the report.  In
> that case, I'll just report the missing doc and strange behavior.
> Thanks.

(setq server-raise-frame nil) in my init.el does indeed fix the unwanted behaviour. I will leave it to you to report what you have found.

Thanks again for the help with this problem, it was rather frustrating.

-Trygve

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

trygve.flathen@gmail.com writes:

> (setq server-raise-frame nil) in my init.el does indeed fix the
> unwanted behaviour.

Thanks, that's good news.

> I will leave it to you to report what you have found.

Ok, will do.


Regards,

Michael.

Re: closing emacsclient always focuses another emacs window

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Ok, will do.

I finally managed to create a bug report: bug#17111.  I found some more
cases of strange behavior in the meantime.  If you think you can
contribute some information or have other problems with the C-x #
switching behavior, please join the discussion, e.g. by sending a
message to

    17111@debbugs.gnu.org


Thanks,

Michael.