* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
@ 2012-03-27 18:56 Dani Moncayo
2012-03-30 17:01 ` Chong Yidong
0 siblings, 1 reply; 29+ messages in thread
From: Dani Moncayo @ 2012-03-27 18:56 UTC (permalink / raw)
To: 11102
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-03-27 18:56 bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process Dani Moncayo
@ 2012-03-30 17:01 ` Chong Yidong
2012-03-30 17:45 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Chong Yidong @ 2012-03-30 17:01 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 11102
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?
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-03-30 17:01 ` Chong Yidong
@ 2012-03-30 17:45 ` Eli Zaretskii
2012-03-30 20:29 ` Juanma Barranquero
2012-04-12 18:11 ` Juanma Barranquero
0 siblings, 2 replies; 29+ messages in thread
From: Eli Zaretskii @ 2012-03-30 17:45 UTC (permalink / raw)
To: Chong Yidong, Juanma Barranquero; +Cc: 11102
> 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?
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-03-30 17:45 ` Eli Zaretskii
@ 2012-03-30 20:29 ` Juanma Barranquero
2012-04-12 18:11 ` Juanma Barranquero
1 sibling, 0 replies; 29+ messages in thread
From: Juanma Barranquero @ 2012-03-30 20:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11102, Chong Yidong
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-03-30 17:45 ` Eli Zaretskii
2012-03-30 20:29 ` Juanma Barranquero
@ 2012-04-12 18:11 ` Juanma Barranquero
2012-04-13 14:38 ` Eli Zaretskii
1 sibling, 1 reply; 29+ messages in thread
From: Juanma Barranquero @ 2012-04-12 18:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11102, Chong Yidong
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-12 18:11 ` Juanma Barranquero
@ 2012-04-13 14:38 ` Eli Zaretskii
2012-04-13 15:20 ` Dani Moncayo
` (2 more replies)
0 siblings, 3 replies; 29+ messages in thread
From: Eli Zaretskii @ 2012-04-13 14:38 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 11102, cyd
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-13 14:38 ` Eli Zaretskii
@ 2012-04-13 15:20 ` Dani Moncayo
2012-04-13 15:46 ` Eli Zaretskii
2012-04-13 16:10 ` Juanma Barranquero
2012-04-14 4:55 ` Chong Yidong
2 siblings, 1 reply; 29+ messages in thread
From: Dani Moncayo @ 2012-04-13 15:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Juanma Barranquero, 11102, cyd
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-13 15:20 ` Dani Moncayo
@ 2012-04-13 15:46 ` Eli Zaretskii
2012-04-13 23:49 ` Juanma Barranquero
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2012-04-13 15:46 UTC (permalink / raw)
To: Dani Moncayo; +Cc: lekktu, 11102, cyd
> 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).
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-13 14:38 ` Eli Zaretskii
2012-04-13 15:20 ` Dani Moncayo
@ 2012-04-13 16:10 ` Juanma Barranquero
2012-04-13 16:13 ` Juanma Barranquero
2012-04-14 4:55 ` Chong Yidong
2 siblings, 1 reply; 29+ messages in thread
From: Juanma Barranquero @ 2012-04-13 16:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11102, cyd
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-13 16:10 ` Juanma Barranquero
@ 2012-04-13 16:13 ` Juanma Barranquero
2012-04-13 17:55 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Juanma Barranquero @ 2012-04-13 16:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11102, cyd
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-13 16:13 ` Juanma Barranquero
@ 2012-04-13 17:55 ` Eli Zaretskii
2012-04-13 19:15 ` Juanma Barranquero
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2012-04-13 17:55 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 11102, cyd
> 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?
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-13 17:55 ` Eli Zaretskii
@ 2012-04-13 19:15 ` Juanma Barranquero
2012-04-13 21:00 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Juanma Barranquero @ 2012-04-13 19:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11102, cyd
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-13 19:15 ` Juanma Barranquero
@ 2012-04-13 21:00 ` Eli Zaretskii
0 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2012-04-13 21:00 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 11102, cyd
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-13 15:46 ` Eli Zaretskii
@ 2012-04-13 23:49 ` Juanma Barranquero
2012-04-14 4:03 ` Chong Yidong
0 siblings, 1 reply; 29+ messages in thread
From: Juanma Barranquero @ 2012-04-13 23:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11102, cyd
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-13 23:49 ` Juanma Barranquero
@ 2012-04-14 4:03 ` Chong Yidong
2012-04-14 7:26 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Chong Yidong @ 2012-04-14 4:03 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 11102
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-13 14:38 ` Eli Zaretskii
2012-04-13 15:20 ` Dani Moncayo
2012-04-13 16:10 ` Juanma Barranquero
@ 2012-04-14 4:55 ` Chong Yidong
2012-04-14 5:34 ` Chong Yidong
2012-04-14 9:36 ` Eli Zaretskii
2 siblings, 2 replies; 29+ messages in thread
From: Chong Yidong @ 2012-04-14 4:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Juanma Barranquero, 11102
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-14 4:55 ` Chong Yidong
@ 2012-04-14 5:34 ` Chong Yidong
2012-04-14 7:25 ` Eli Zaretskii
2012-04-14 9:36 ` Eli Zaretskii
1 sibling, 1 reply; 29+ messages in thread
From: Chong Yidong @ 2012-04-14 5:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Juanma Barranquero, 11102
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-14 5:34 ` Chong Yidong
@ 2012-04-14 7:25 ` Eli Zaretskii
2012-04-14 8:17 ` Chong Yidong
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2012-04-14 7:25 UTC (permalink / raw)
To: Chong Yidong; +Cc: lekktu, 11102
> 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?
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-14 4:03 ` Chong Yidong
@ 2012-04-14 7:26 ` Eli Zaretskii
0 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2012-04-14 7:26 UTC (permalink / raw)
To: Chong Yidong; +Cc: lekktu, 11102
> 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?
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-14 7:25 ` Eli Zaretskii
@ 2012-04-14 8:17 ` Chong Yidong
2012-04-14 9:28 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Chong Yidong @ 2012-04-14 8:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: lekktu, 11102
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-14 8:17 ` Chong Yidong
@ 2012-04-14 9:28 ` Eli Zaretskii
2012-04-14 10:33 ` Chong Yidong
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2012-04-14 9:28 UTC (permalink / raw)
To: Chong Yidong; +Cc: lekktu, 11102
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-14 4:55 ` Chong Yidong
2012-04-14 5:34 ` Chong Yidong
@ 2012-04-14 9:36 ` Eli Zaretskii
1 sibling, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2012-04-14 9:36 UTC (permalink / raw)
To: Chong Yidong; +Cc: lekktu, 11102
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-14 9:28 ` Eli Zaretskii
@ 2012-04-14 10:33 ` Chong Yidong
2012-04-14 11:37 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Chong Yidong @ 2012-04-14 10:33 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: lekktu, 11102
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-14 10:33 ` Chong Yidong
@ 2012-04-14 11:37 ` Eli Zaretskii
2012-04-14 13:18 ` Chong Yidong
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2012-04-14 11:37 UTC (permalink / raw)
To: Chong Yidong; +Cc: lekktu, 11102
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-14 11:37 ` Eli Zaretskii
@ 2012-04-14 13:18 ` Chong Yidong
2012-04-14 13:34 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Chong Yidong @ 2012-04-14 13:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: lekktu, 11102
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-14 13:18 ` Chong Yidong
@ 2012-04-14 13:34 ` Eli Zaretskii
2012-04-15 8:53 ` Chong Yidong
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2012-04-14 13:34 UTC (permalink / raw)
To: Chong Yidong; +Cc: lekktu, 11102
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-14 13:34 ` Eli Zaretskii
@ 2012-04-15 8:53 ` Chong Yidong
2012-04-20 8:23 ` Dani Moncayo
0 siblings, 1 reply; 29+ messages in thread
From: Chong Yidong @ 2012-04-15 8:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: lekktu, 11102
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-15 8:53 ` Chong Yidong
@ 2012-04-20 8:23 ` Dani Moncayo
2012-04-20 19:10 ` Dani Moncayo
0 siblings, 1 reply; 29+ messages in thread
From: Dani Moncayo @ 2012-04-20 8:23 UTC (permalink / raw)
To: Chong Yidong; +Cc: lekktu, 11102
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
2012-04-20 8:23 ` Dani Moncayo
@ 2012-04-20 19:10 ` Dani Moncayo
0 siblings, 0 replies; 29+ messages in thread
From: Dani Moncayo @ 2012-04-20 19:10 UTC (permalink / raw)
To: Chong Yidong; +Cc: lekktu, 11102
>> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2012-04-20 19:10 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-27 18:56 bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process Dani Moncayo
2012-03-30 17:01 ` Chong Yidong
2012-03-30 17:45 ` Eli Zaretskii
2012-03-30 20:29 ` Juanma Barranquero
2012-04-12 18:11 ` Juanma Barranquero
2012-04-13 14:38 ` Eli Zaretskii
2012-04-13 15:20 ` Dani Moncayo
2012-04-13 15:46 ` Eli Zaretskii
2012-04-13 23:49 ` Juanma Barranquero
2012-04-14 4:03 ` Chong Yidong
2012-04-14 7:26 ` Eli Zaretskii
2012-04-13 16:10 ` Juanma Barranquero
2012-04-13 16:13 ` Juanma Barranquero
2012-04-13 17:55 ` Eli Zaretskii
2012-04-13 19:15 ` Juanma Barranquero
2012-04-13 21:00 ` Eli Zaretskii
2012-04-14 4:55 ` Chong Yidong
2012-04-14 5:34 ` Chong Yidong
2012-04-14 7:25 ` Eli Zaretskii
2012-04-14 8:17 ` Chong Yidong
2012-04-14 9:28 ` Eli Zaretskii
2012-04-14 10:33 ` Chong Yidong
2012-04-14 11:37 ` Eli Zaretskii
2012-04-14 13:18 ` Chong Yidong
2012-04-14 13:34 ` Eli Zaretskii
2012-04-15 8:53 ` Chong Yidong
2012-04-20 8:23 ` Dani Moncayo
2012-04-20 19:10 ` Dani Moncayo
2012-04-14 9:36 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).