bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Sat, 14 Apr 2012 16:34:32 +0300

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]