[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whol
From: |
Eli Zaretskii |
Subject: |
bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process |
Date: |
Fri, 13 Apr 2012 18:46:56 +0300 |
> 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, 2012/04/13
bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process, Chong Yidong, 2012/04/14