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

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

[Dani Moncayo]

Hi,

Here's a recipe:
0. emacs -Q
1. M-x server-start

From some terminal:
2. emacsclient -c -n some-file

On the new Emacs frame just created:
3. C-x C-c

--> Expected behavior: The new frame is deleted, but not the server frame [1].
--> Observed behavior: Both frames are deleted (i.e. the whole Emacs process).

BTW, if I omit "some-file" in step #2 (so that the new frame shows the
*scratch* buffer), the observed behavior is the expected one.


--- Footnotes: ------

[1] Quotation from (info "(emacs)emacsclient Options"):

     If you type `C-x C-c' (`save-buffers-kill-terminal') in an Emacs
  frame created with `emacsclient', via the `-c' or `-t' options, Emacs
  deletes the frame instead of killing the Emacs process itself.  [...]



In GNU Emacs 24.0.94.1 (i386-mingw-nt6.1.7601)
 of 2012-03-23 on DANI-PC
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -IC:/emacs/libs/giflib-4.1.4-1/include
 -IC:/emacs/libs/gnutls-3.0.16/include -IC:/emacs/libs/jpeg-6b-4/include
 -IC:/emacs/libs/libpng-1.4.10 -IC:/emacs/libs/libxpm-3.5.8/include
 -IC:/emacs/libs/libxpm-3.5.8/src -IC:/emacs/libs/tiff-3.8.2-1/include
 -IC:/emacs/libs/zlib-1.2.6'


-- 
Dani Moncayo

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

[Chong Yidong]

Dani Moncayo <dmoncayo@gmail.com> writes:

> 0. emacs -Q
> 1. M-x server-start
>
> From some terminal:
> 2. emacsclient -c -n some-file
>
> On the new Emacs frame just created:
> 3. C-x C-c
>
> --> Expected behavior: The new frame is deleted, but not the server frame [1].
> --> Observed behavior: Both frames are deleted (i.e. the whole Emacs process).

I can't reproduce this with latest trunk (x86_64-unknown-linux-gnu, GTK+
2.24.6).  Maybe this is Windows specific?

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Date: Sat, 31 Mar 2012 01:01:51 +0800
> Cc: 11102@debbugs.gnu.org
> 
> Dani Moncayo <dmoncayo@gmail.com> writes:
> 
> > 0. emacs -Q
> > 1. M-x server-start
> >
> > From some terminal:
> > 2. emacsclient -c -n some-file
> >
> > On the new Emacs frame just created:
> > 3. C-x C-c
> >
> > --> Expected behavior: The new frame is deleted, but not the server frame [1].
> > --> Observed behavior: Both frames are deleted (i.e. the whole Emacs process).
> 
> I can't reproduce this with latest trunk (x86_64-unknown-linux-gnu, GTK+
> 2.24.6).  Maybe this is Windows specific?

It most probably is.  Juanma, could you take a look, please?

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

[Juanma Barranquero]

On Fri, Mar 30, 2012 at 19:45, Eli Zaretskii <eliz@gnu.org> wrote:

> It most probably is.

At least, it is repeatable on Windows.

> Juanma, could you take a look, please?

Yes, I was planning to delve into it during the weekend.

    Juanma

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

[Juanma Barranquero]

On Fri, Mar 30, 2012 at 19:45, Eli Zaretskii <eliz@gnu.org> wrote:

> It most probably is.  Juanma, could you take a look, please?

A little after current_frame is forced to 0 on Windows (in the -c / -t cases):

#ifdef WINDOWSNT
  /* Emacs on Windows does not support GUI and console frames in the same
     instance.  So, it makes sense to treat the -t and -c options as
     equivalent, and open a new frame regardless of whether the running
     instance is GUI or console.  Ideally, we would only set tty = 1 when
     the instance is running in a console, but alas we don't know that.
     The simplest workaround is to always ask for a tty frame, and let
     server.el check whether it makes sense.  */
  if (tty || !current_frame)
    {
      display = (const char *) ttyname (fileno (stdout));
      current_frame = 0;
      tty = 1;
    }
#endif

there's this bit of code (non-WINDOWSNT-specific):

  /* --no-wait implies --current-frame on ttys when there are file
     arguments or expressions given.  */
  if (nowait && tty && argc - optind > 0)
    current_frame = 1;

which causes the bug. I'm not sure I understand the logic after that
code, and even less sure it makes sense on Windows. WDYT?

    Juanma

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

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 12 Apr 2012 20:11:38 +0200
> Cc: Chong Yidong <cyd@gnu.org>, dmoncayo@gmail.com, 11102@debbugs.gnu.org
> 
> On Fri, Mar 30, 2012 at 19:45, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > It most probably is.  Juanma, could you take a look, please?
> 
> A little after current_frame is forced to 0 on Windows (in the -c / -t cases):
> 
> #ifdef WINDOWSNT
>   /* Emacs on Windows does not support GUI and console frames in the same
>      instance.  So, it makes sense to treat the -t and -c options as
>      equivalent, and open a new frame regardless of whether the running
>      instance is GUI or console.  Ideally, we would only set tty = 1 when
>      the instance is running in a console, but alas we don't know that.
>      The simplest workaround is to always ask for a tty frame, and let
>      server.el check whether it makes sense.  */
>   if (tty || !current_frame)
>     {
>       display = (const char *) ttyname (fileno (stdout));
>       current_frame = 0;
>       tty = 1;
>     }
> #endif
> 
> there's this bit of code (non-WINDOWSNT-specific):
> 
>   /* --no-wait implies --current-frame on ttys when there are file
>      arguments or expressions given.  */
>   if (nowait && tty && argc - optind > 0)
>     current_frame = 1;
> 
> which causes the bug. I'm not sure I understand the logic after that
> code, and even less sure it makes sense on Windows. WDYT?

In that case, I don't understand why did Dani expect something
different from what he saw.  I see the same behavior on GNU/Linux: if
emacsclient is invoked with -n, "C-x C-c" kills Emacs.  Perhaps the
bug is that we create a new frame on Windows even though the server
receives the -current-frame parameter.  Why doesn't server.el on
Windows honor that parameter?

As for the logic behind the above code, AFAIU -n means emacsclient is
used as a way of asking Emacs to visit a file without any special
handling; in particular, "C-x #" does _not_ kill the buffer visiting
that file.  So killing the entire session upon "C-x C-c" makes sense
in this case.

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

[Dani Moncayo]

> In that case, I don't understand why did Dani expect something
> different from what he saw.

??
As I said in the first post, I expect the behavior documented in node
"(emacs)emacsclient Options":

    If you type `C-x C-c' (`save-buffers-kill-terminal') in an Emacs
 frame created with `emacsclient', via the `-c' or `-t' options, Emacs
 deletes the frame instead of killing the Emacs process itself.  [...]

>  I see the same behavior on GNU/Linux: if
> emacsclient is invoked with -n, "C-x C-c" kills Emacs.

If you used also -t or -c, then the the bug is also on that platform
(according to the manual).

> As for the logic behind the above code, AFAIU -n means emacsclient is
> used as a way of asking Emacs to visit a file without any special
> handling; in particular, "C-x #" does _not_ kill the buffer visiting
> that file.

According to the manual, "-n" just means "no wait for the server to
return control":

  `-n'
  `--no-wait'
       Let `emacsclient' exit immediately, instead of waiting until all
       server buffers are finished.  You can take as long as you like to
       edit the server buffers within Emacs, and they are _not_ killed
       when you type `C-x #' in them.


> So killing the entire session upon "C-x C-c" makes sense
> in this case.

I don't see how that interpretation can be deducted from the current manual.

Besides, as I said in the first post, the observed behavior also
varies when you call emacsclient with and without a filename.

-- 
Dani Moncayo

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

[Eli Zaretskii]

> Date: Fri, 13 Apr 2012 17:20:35 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Juanma Barranquero <lekktu@gmail.com>, cyd@gnu.org, 11102@debbugs.gnu.org
> 
> > In that case, I don't understand why did Dani expect something
> > different from what he saw.
> 
> ??
> As I said in the first post, I expect the behavior documented in node
> "(emacs)emacsclient Options":
> 
>     If you type `C-x C-c' (`save-buffers-kill-terminal') in an Emacs
>  frame created with `emacsclient', via the `-c' or `-t' options, Emacs
>  deletes the frame instead of killing the Emacs process itself.  [...]

Well, it also says

     When you finish editing FILE in the Emacs server, type `C-x #'
  (`server-edit') in its buffer.  This saves the file and sends a message
  back to the `emacsclient' program, telling it to exit.

which is not what happens under -n.

So this may well be a documentation bug.  (In general, I find the
emacsclient documentation to be confusing, even after a lot of
improvements done as part of 24.1 pretest.  It could be that the
various options and interactions between them are hard to document
clearly.)

> >  I see the same behavior on GNU/Linux: if
> > emacsclient is invoked with -n, "C-x C-c" kills Emacs.
> 
> If you used also -t or -c

I used the exact command that you show in your report.

> then the the bug is also on that platform (according to the manual).

The implementation clearly shows that the behavior was intended.

> > As for the logic behind the above code, AFAIU -n means emacsclient is
> > used as a way of asking Emacs to visit a file without any special
> > handling; in particular, "C-x #" does _not_ kill the buffer visiting
> > that file.
> 
> According to the manual, "-n" just means "no wait for the server to
> return control":
> 
>   `-n'
>   `--no-wait'
>        Let `emacsclient' exit immediately, instead of waiting until all
>        server buffers are finished.  You can take as long as you like to
>        edit the server buffers within Emacs, and they are _not_ killed
>        when you type `C-x #' in them.

Like I said: I think the manual is incomplete and potentially
misleading here.

> > So killing the entire session upon "C-x C-c" makes sense
> > in this case.
> 
> I don't see how that interpretation can be deducted from the current manual.

I just said the behavior makes sense to me, that's all.

> Besides, as I said in the first post, the observed behavior also
> varies when you call emacsclient with and without a filename.

Again, a deficiency in the manual.  The code and its commentary are
very clear:

  /* --no-wait implies --current-frame on ttys when there are file
     arguments or expressions given.  */
  if (nowait && tty && argc - optind > 0)
    current_frame = 1;

which again makes sense.

Therefore, I think we should (1) fix the manual to document this
behavior, and (2) fix the Windows port to use one of the existing
frames instead of popping up a new frame (unless Juanma explains why
the current behavior on Windows makes sense).

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

[Juanma Barranquero]

On Fri, Apr 13, 2012 at 17:46, Eli Zaretskii <eliz@gnu.org> wrote:

>  /* --no-wait implies --current-frame on ttys when there are file
>     arguments or expressions given.  */
>  if (nowait && tty && argc - optind > 0)
>    current_frame = 1;

OTOH, this explicitly refers to ttys. What does

  emacs -Q -f server-start
  emacsclient -c -n somefile

do in a GUI emacs on GNU/Linux? Does it create a new frame or not?
(I'm assuming "emacsclient -c -n" without a file arg creates one.)

    Juanma

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

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> OTOH, this explicitly refers to ttys. What does
>
>   emacs -Q -f server-start
>   emacsclient -c -n somefile
>
> do in a GUI emacs on GNU/Linux? Does it create a new frame or not?
> (I'm assuming "emacsclient -c -n" without a file arg creates one.)

Yes, it creates a new frame.

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Dani Moncayo <dmoncayo@gmail.com>,  11102@debbugs.gnu.org
> Date: Sat, 14 Apr 2012 12:03:51 +0800
> 
> Juanma Barranquero <lekktu@gmail.com> writes:
> 
> > OTOH, this explicitly refers to ttys. What does
> >
> >   emacs -Q -f server-start
> >   emacsclient -c -n somefile
> >
> > do in a GUI emacs on GNU/Linux? Does it create a new frame or not?
> > (I'm assuming "emacsclient -c -n" without a file arg creates one.)
> 
> Yes, it creates a new frame.

And what happens if the server runs in a TTY session?

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

[Juanma Barranquero]

On Fri, Apr 13, 2012 at 16:38, Eli Zaretskii <eliz@gnu.org> wrote:

> Perhaps the
> bug is that we create a new frame on Windows even though the server
> receives the -current-frame parameter.  Why doesn't server.el on
> Windows honor that parameter?

I think it is a bug, yes. On a tty session,

  emacs -Q -nw -f server-start
  emacsclient -c -n

the emacs server does not get a second frame, though you get a
spurious message "When done with this frame, type C-x 5 0" (I
debbugged it a bit and I think a second frame is being created and
then destroyed).

    Juanma

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

[Juanma Barranquero]

On Fri, Apr 13, 2012 at 17:46, Eli Zaretskii <eliz@gnu.org> wrote:

> Therefore, I think we should (1) fix the manual to document this
> behavior, and (2) fix the Windows port to use one of the existing
> frames instead of popping up a new frame (unless Juanma explains why
> the current behavior on Windows makes sense).

No, I don't think it makes sense, IMO it's fallout from fixing the
"emacsclient vs. new frames" stuff on Windows.

    Juanma

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

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 13 Apr 2012 18:13:26 +0200
> Cc: 11102@debbugs.gnu.org, cyd@gnu.org
> 
> On Fri, Apr 13, 2012 at 17:46, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Therefore, I think we should (1) fix the manual to document this
> > behavior, and (2) fix the Windows port to use one of the existing
> > frames instead of popping up a new frame (unless Juanma explains why
> > the current behavior on Windows makes sense).
> 
> No, I don't think it makes sense, IMO it's fallout from fixing the
> "emacsclient vs. new frames" stuff on Windows.

Could you please look into fixing that?

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

[Juanma Barranquero]

On Fri, Apr 13, 2012 at 19:55, Eli Zaretskii <eliz@gnu.org> wrote:

> Could you please look into fixing that?

Yes, of course.

Will you take care of fixing the docs?

    Juanma

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

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 13 Apr 2012 21:15:55 +0200
> Cc: 11102@debbugs.gnu.org, cyd@gnu.org
> 
> On Fri, Apr 13, 2012 at 19:55, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Could you please look into fixing that?
> 
> Yes, of course.
> 
> Will you take care of fixing the docs?

Yes, of course.

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> In that case, I don't understand why did Dani expect something
> different from what he saw.  I see the same behavior on GNU/Linux: if
> emacsclient is invoked with -n, "C-x C-c" kills Emacs.  Perhaps the
> bug is that we create a new frame on Windows even though the server
> receives the -current-frame parameter.  Why doesn't server.el on
> Windows honor that parameter?

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.

The role of -n is as follows: *without* -n, i.e. if emacsclient waits
for edits to finish, the C-x C-c that deletes the client frame should
also mark the client's edits as finished.

I've updated the manual to improve the description of this.  Is it clear
enough now?

If on a client frame created by "emacsclient -c -n" the C-x C-c command
kills Emacs, that is indeed a bug.  My guess would be that the `client'
frame parameter is not getting correctly assigned to the newly-created
frame on Windows, due to the extra juggling in the #ifdef WINDOWSNT code
segment Juanma pointed out.

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

[Chong Yidong]

Chong Yidong <cyd@gnu.org> writes:

> If on a client frame created by "emacsclient -c -n" the C-x C-c command
> kills Emacs, that is indeed a bug.  My guess would be that the `client'
> frame parameter is not getting correctly assigned to the newly-created
> frame on Windows, due to the extra juggling in the #ifdef WINDOWSNT code
> segment Juanma pointed out.

Took a quick look, and indeed the "set tty = 1 on Windows" hack does
seem to be at fault.  Here's my diagnosis:

  if (tty || !current_frame)
    {
      display = (const char *) ttyname (0);  /* Arg is ignored.  */
      current_frame = 0;
      tty = 1;
    }

  ...

  /* --no-wait implies --current-frame on ttys when there are file
     arguments or expressions given.  */
  if (nowait && tty && argc - optind > 0)
    current_frame = 1;

When tty = 1, if there are also -n and filename arguments, emacsclient
assumes that a current Emacs frame must be used.  This assumption is not
correct if the tty = 1 is because of the Window hack.  As a result, the
server calls `server-select-display', which ends up trying to create a
new frame on the display ttyname(0), contra the "Arg is ignored"
comment.  That new frame, if created, lacks the `client' frame parameter
for C-x C-c to work right.

Does the following patch DTRT?  This is an attempt at making a minimal
change, for Emacs 24.1.  For the trunk, I think it is worth trying to
untangle the logic properly, but that will needs Someone(tm) to work on
it who has access to a Windows box.


=== modified file 'lisp/server.el'
*** lisp/server.el	2012-04-04 17:13:00 +0000
--- lisp/server.el	2012-04-14 05:29:24 +0000
***************
*** 1136,1141 ****
--- 1136,1145 ----
  	    (setq frame
  		  (cond
  		   ((and use-current-frame
+ 			 ;; On Windows, we pass -tty as a hack, using
+ 			 ;; a bogus display name.
+ 			 (or (not (eq window-system 'w32))
+ 			     (equal display "CONOUT$"))
  			 (or (eq use-current-frame 'always)
  			     ;; We can't use the Emacs daemon's
  			     ;; terminal frame.

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: Juanma Barranquero <lekktu@gmail.com>,  11102@debbugs.gnu.org
> Date: Sat, 14 Apr 2012 13:34:27 +0800
> 
> Chong Yidong <cyd@gnu.org> writes:
> 
> > If on a client frame created by "emacsclient -c -n" the C-x C-c command
> > kills Emacs, that is indeed a bug.  My guess would be that the `client'
> > frame parameter is not getting correctly assigned to the newly-created
> > frame on Windows, due to the extra juggling in the #ifdef WINDOWSNT code
> > segment Juanma pointed out.
> 
> Took a quick look, and indeed the "set tty = 1 on Windows" hack does
> seem to be at fault.

Like I said, I see the same "bug" on GNU/Linux, when the server runs
in a TTY session (couldn't check in a GUI session).  Are you talking
about GUI sessions only?

> Here's my diagnosis:
> 
>   if (tty || !current_frame)
>     {
>       display = (const char *) ttyname (0);  /* Arg is ignored.  */
>       current_frame = 0;
>       tty = 1;
>     }
> 
>   ...
> 
>   /* --no-wait implies --current-frame on ttys when there are file
>      arguments or expressions given.  */
>   if (nowait && tty && argc - optind > 0)
>     current_frame = 1;
> 
> When tty = 1, if there are also -n and filename arguments, emacsclient
> assumes that a current Emacs frame must be used.  This assumption is not
> correct if the tty = 1 is because of the Window hack.

But is that assumption correct if tty = 1 on GNU/Linux?  In a previous
mail you said:

> 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?  If not,
what else am I missing?

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> 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

I do see a discrepancy with "emacsclient -t -n foo.txt"; in that
(slightly ill-defined) case, the -n negates the -t causing the edits to
be made in the existing Emacs terminal frame.  But that doesn't seem to
be what you're referring to.

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: lekktu@gmail.com,  11102@debbugs.gnu.org
> Date: Sat, 14 Apr 2012 16:17:07 +0800
> 
> Eli Zaretskii <eliz@gnu.org> 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.

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> Try doing this with Emacs built --without-x

Hmm, what I get with --without-x is

1. emacs -Q -nw -f server-start
2. emacsclient -c -n foo.txt
*ERROR*: Don't know how to create a frame on window system x

so I guess some more intelligent error handling is needed here.  If I
use "-t -n foo.txt", then (as I noted in my earlier email) the file is
opened in the existing Emacs terminal frame.  I'll see what I can do
about these issues, but they are basically not urgent to fix for 24.1.

The issue which Dani and Juanma were talking about is a separate one:
for a graphical Emacs on Windows, "emacsclient -c -n foo.txt" ought to
create a new frame with a `client' parameter, so that C-x C-c exits
Emacs instead of closing just that frame.  That is the intended
behavior, which is also the behavior on GNU/Linux when there is a
graphical display available.  I think the patch I posted earlier should
DTRT for Windows, if you or Juanma can try it.

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: lekktu@gmail.com,  11102@debbugs.gnu.org
> Date: Sat, 14 Apr 2012 18:33:39 +0800
> 
> The issue which Dani and Juanma were talking about is a separate one:
> for a graphical Emacs on Windows, "emacsclient -c -n foo.txt" ought to
> create a new frame with a `client' parameter, so that C-x C-c exits
> Emacs instead of closing just that frame.

Now I'm completely confused: didn't you say that "C-x C-c" should
_not_ exit Emacs in this case?

> That is the intended behavior, which is also the behavior on
> GNU/Linux when there is a graphical display available.  I think the
> patch I posted earlier should DTRT for Windows, if you or Juanma can
> try it.

Why does it make sense to have "-c -n" behave differently from "-t -n"?
Isn't this terribly confusing for users?  AFAIU, these two are variants
are otherwise very similar to each other: they both reuse the current
frame on the same terminal where the server is running.

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> The issue which Dani and Juanma were talking about is a separate one:
>> for a graphical Emacs on Windows, "emacsclient -c -n foo.txt" ought to
>> create a new frame with a `client' parameter, so that C-x C-c exits
>> Emacs instead of closing just that frame.
>
> Now I'm completely confused: didn't you say that "C-x C-c" should
> _not_ exit Emacs in this case?

Sorry, I miswrote.  Indeed, C-x C-c should _not_ exit Emacs in that
case.

> Why does it make sense to have "-c -n" behave differently from
> "-t -n"?

The "-t -n" case is an abberation; emacsclient could even signal an
error for that, because it is saying "open on this text terminal, but
don't wait", which is nonsensical.  The current behavior, of opening on
another text terminal, is a fudge---and one that doesn't work for the
Emacs daemon.  For that reason, the discrepancy you point out is not
important.

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: lekktu@gmail.com,  11102@debbugs.gnu.org
> Date: Sat, 14 Apr 2012 21:18:43 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The issue which Dani and Juanma were talking about is a separate one:
> >> for a graphical Emacs on Windows, "emacsclient -c -n foo.txt" ought to
> >> create a new frame with a `client' parameter, so that C-x C-c exits
> >> Emacs instead of closing just that frame.
> >
> > Now I'm completely confused: didn't you say that "C-x C-c" should
> > _not_ exit Emacs in this case?
> 
> Sorry, I miswrote.  Indeed, C-x C-c should _not_ exit Emacs in that
> case.

I'm relieved ;-)

> > Why does it make sense to have "-c -n" behave differently from
> > "-t -n"?
> 
> The "-t -n" case is an abberation; emacsclient could even signal an
> error for that, because it is saying "open on this text terminal, but
> don't wait", which is nonsensical.  The current behavior, of opening on
> another text terminal, is a fudge---and one that doesn't work for the
> Emacs daemon.  For that reason, the discrepancy you point out is not
> important.

Maybe it's just me, but the "aberration" sounds good to me, and,
again, makes "-c -n" and "-t -n" behave very similar, except for the
effect of "C-x C-c".  I would suggest to make them similar in that
respect as well, so as to cause a bit less mental disorder to users
than we do now.

If we do leave the different "C-x C-c" behavior, we need to clearly
document that in the manual, I think.

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> If we do leave the different "C-x C-c" behavior, we need to clearly
> document that in the manual, I think.

I've updated the manual accordingly.

I've also committed a fix for the "-t -n" handling which should fix the
problem observed on Windows.  It is on the emacs-24 branch, since AFAICT
the additional Windows code causing this problem is new since 23.4.
Someone with access to Windows please check if it DTRT.

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

[Dani Moncayo]

> I've also committed a fix for the "-t -n" handling which should fix the
> problem observed on Windows.  It is on the emacs-24 branch, since AFAICT
> the additional Windows code causing this problem is new since 23.4.
> Someone with access to Windows please check if it DTRT.

Sorry for not replying.  I was waiting for this change to be on the
trunk, because I've not pulled the emacs-24 branch.  When this change
arrives to the trunk, I'll test it.

Thanks.

-- 
Dani Moncayo

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

[Dani Moncayo]

>> I've also committed a fix for the "-t -n" handling which should fix the
>> problem observed on Windows.  It is on the emacs-24 branch, since AFAICT
>> the additional Windows code causing this problem is new since 23.4.
>> Someone with access to Windows please check if it DTRT.
>
> Sorry for not replying.  I was waiting for this change to be on the
> trunk, because I've not pulled the emacs-24 branch.  When this change
> arrives to the trunk, I'll test it.

I've just tested this (the original bug recipe) with the latest trunk
(revno 107976) and the bug seems to be fixed.

Thank you.

-- 
Dani Moncayo

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: Juanma Barranquero <lekktu@gmail.com>,  dmoncayo@gmail.com,  11102@debbugs.gnu.org
> Date: Sat, 14 Apr 2012 12:55:10 +0800
> 
> I've updated the manual to improve the description of this.  Is it clear
> enough now?

Let's wait with the ``clear'' part until we have a complete
understanding what is or should be the correct behavior; see my other
mail.

But I do know that what you wrote is inaccurate for MS-Windows.  In
this part:

  On GNU and Unix systems, Emacs can create a graphical frame even if it
  was started in a text-only terminal, provided it is able to connect to
  a graphical display.  On systems such as MS-Windows, it cannot create
  graphical frames if it was started from a text terminal
  (@pxref{Windows Startup, emacsclient}).  If Emacs cannot connect to a
  graphical display for any reason, it instead creates a new client
  frame on the text terminal from which you invoked
  @command{emacsclient} (@pxref{Non-Window Terminals}).

the last sentence tells something that doesn't happen on Windows.  The
new client frame is created on the text terminal where _Emacs_ was
invoked, not where emacsclient was invoked.  On Windows, a program can
have only one console at any given time, so Emacs cannot open a text
frame on a different console.