Subject: Re: bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process

From: Eli Zaretskii <[email-masked]>
Date: Sat, 14 Apr 2012 12:28:57 +0300

> From: Chong Yidong <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Sat, 14 Apr 2012 16:17:07 +0800
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> >> With the -c option, a client frame is created, so C-x C-c should delete
> >> the frame without killing the main Emacs session, whether or not there
> >> is an -n option.
> >
> > This seems to imply that using "emacsclient -c -n FILE" on a Posix
> > host should _not_ kill emacs when "C-x C-c" is typed.  And yet in my
> > testing, it does, with the emacs-24 branch built just now, when the
> > server runs in a TTY session.  Are you saying that the effect of -n
> > depends also on whether the server runs in a TTY session?
> 
> That's not what I see with latest emacs-24 branch
> (x86_64-unknown-linux-gnu):
> 
> 1. emacs -Q -nw -f server-start
> 2. [in another xterm]   emacsclient -c -n foo.txt
> 3. [in the new X frame] C-x C-c
> 
>   => frame is deleted, but Emacs session is still alive

Try doing this with Emacs built --without-x, or in a remote TTY login
that doesn't support X forwarding.

What I did, exactly, is this:

 (1) login via PuTTY into my fencepost account (you should be able to
     reproduce using 'ssh' instead) and chdir to the emacs-24 branch
 (2) ./src/emacs -Q -f server-start
 (3) login again via PuTYY, which opens another remote terminal
     window, and chdir to the same directory
 (4) ./lib-src/emacsclient -c -n README

At this point, I see the file README being visited in the Emacs
session opened by (2), but in the original frame (the mode line still
shows "F1", not "F2").

 (5) In the session created by (2): C-x C-c

   => the Emacs session is terminated and I see the shell prompt.

In general, if a new frame isn't created by emacsclient request, it
makes sense to me that "C-x C-c" terminates the Emacs session, rather
than just deleting the new frame.  That is why I said I didn't think
this was a bug.  Now it seems that emacsclient is even more messed up
than I thought in this regard, since the conditions for creating a new
frame (and thus for deleting it) involve all kinds of subtle factors.