GNU bug report logs - #5616
23.1.92; `delete-frame' deletes the last frame when emacsclient runs

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5616 in the body.
You can then email your comments to 5616 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: p1ng2h3ng <at> gmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1.92; `delete-frame' deletes the last frame when emacsclient runs
Date: Sun, 21 Feb 2010 17:25:09 +0800

when I run `emacs --daemon -Q' and `emacsclient -nc', then if I try `M-x
delete-frame', emacsclient seems will delete last remaining frame
without check or remind.

I think it should be mentioned in the manuals, but all I got said emacs
will not to delete the last frame, even you try `M-x delete-frame'.

So I think at least there is a doc bug, and manuals should mention about
that.


In GNU Emacs 23.1.92.1 (x86_64-pc-linux-gnu, GTK+ Version 2.16.6)
 of 2010-02-21 on dell.pingz
Windowing system distributor `The X.Org Foundation', version 11.0.10705000
configured using `configure  '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--libdir=/usr/lib64' '--program-suffix=-emacs-23-vcs' '--infodir=/usr/share/info/emacs-23-vcs' '--with-sound' '--with-x' '--without-gconf' '--with-toolkit-scroll-bars' '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xpm' '--with-xft' '--with-libotf' '--with-m17n-flt' '--with-x-toolkit=gtk' '--with-hesiod' '--with-kerberos' '--with-kerberos5' '--with-gpm' '--with-dbus' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-march=nocona -mtune=nocona -O2 -pipe' 'LDFLAGS=-Wl,-O1''

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  minibuffer-depth-indicate-mode: t
  icicle-mode: t
  display-time-mode: t
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x b <return> C-x b g C-g <menu> i c y <tab> C-g <menu> 
e <backspace> d e l <tab> e <tab> f r a <tab> <return> 
<menu> C-g <menu> e m <backspace> <backspace> e <tab> 
m <tab> <tab> e <backspace> <backspace> C-g <menu> 
i c y - c o <tab> <backspace> <backspace> m o <tab> 
<return> c <backspace> C-x b C-g f a <backspace> <backspace> 
C-x b <return> C-x b <return> C-x b C-g C-x b <tab> 
<tab> C-g <return> C-x b C-g C-g C-g <menu> b u f <backspace> 
g <S-iso-lefttab> C-a C-k r e p o <tab> r <tab> <r
eturn>

Recent messages:
Loading /usr/share/emacs/site-lisp/color-theme/themes/color-theme-example.el (source)...done
Loading /usr/share/emacs/site-lisp/color-theme/themes/color-theme-library.el (source)...done
Turning ON Icicle mode...done
Computing completion candidates...
Quit
icicle-abort-recursive-edit: No recursive edit is in progress
Quit
Computing completion candidates...
Displaying completion candidates...
Computing completion candidates...

Load-path shadows:
/usr/share/emacs/site-lisp/cedet/speedbar/speedbar hides /usr/share/emacs/23.1.92/lisp/speedbar
/usr/share/emacs/site-lisp/cedet/speedbar/sb-image hides /usr/share/emacs/23.1.92/lisp/sb-image
/usr/share/emacs/site-lisp/cedet/common/ezimage hides /usr/share/emacs/23.1.92/lisp/ezimage
/usr/share/emacs/site-lisp/cedet/speedbar/dframe hides /usr/share/emacs/23.1.92/lisp/dframe
/usr/share/emacs/site-lisp/ruby-mode/ruby-mode hides /usr/share/emacs/23.1.92/lisp/progmodes/ruby-mode
/usr/share/emacs/site-lisp/cedet/eieio/eieio-base hides /usr/share/emacs/23.1.92/lisp/emacs-lisp/eieio-base
/usr/share/emacs/site-lisp/cedet/eieio/eieio hides /usr/share/emacs/23.1.92/lisp/emacs-lisp/eieio
/usr/share/emacs/site-lisp/cedet/eieio/eieio-speedbar hides /usr/share/emacs/23.1.92/lisp/emacs-lisp/eieio-speedbar
/usr/share/emacs/site-lisp/cedet/eieio/eieio-opt hides /usr/share/emacs/23.1.92/lisp/emacs-lisp/eieio-opt
/usr/share/emacs/site-lisp/cedet/eieio/eieio-datadebug hides /usr/share/emacs/23.1.92/lisp/emacs-lisp/eieio-datadebug
/usr/share/emacs/site-lisp/cedet/eieio/eieio-custom hides /usr/share/emacs/23.1.92/lisp/emacs-lisp/eieio-custom
/usr/share/emacs/site-lisp/cedet/eieio/eieio-comp hides /usr/share/emacs/23.1.92/lisp/emacs-lisp/eieio-comp
/usr/share/emacs/site-lisp/cedet/eieio/chart hides /usr/share/emacs/23.1.92/lisp/emacs-lisp/chart
/usr/share/emacs/site-lisp/cedet/srecode/srecode hides /usr/share/emacs/23.1.92/lisp/cedet/srecode
/usr/share/emacs/site-lisp/cedet/common/cedet-files hides /usr/share/emacs/23.1.92/lisp/cedet/cedet-files
/usr/share/emacs/site-lisp/cedet/common/cedet-cscope hides /usr/share/emacs/23.1.92/lisp/cedet/cedet-cscope
/usr/share/emacs/site-lisp/cedet/semantic/semantic hides /usr/share/emacs/23.1.92/lisp/cedet/semantic
/usr/share/emacs/site-lisp/cedet/common/pulse hides /usr/share/emacs/23.1.92/lisp/cedet/pulse
/usr/share/emacs/site-lisp/cedet/common/mode-local hides /usr/share/emacs/23.1.92/lisp/cedet/mode-local
/usr/share/emacs/site-lisp/cedet/common/inversion hides /usr/share/emacs/23.1.92/lisp/cedet/inversion
/usr/share/emacs/site-lisp/cedet/ede/ede hides /usr/share/emacs/23.1.92/lisp/cedet/ede
/usr/share/emacs/site-lisp/cedet/common/data-debug hides /usr/share/emacs/23.1.92/lisp/cedet/data-debug
/usr/share/emacs/site-lisp/cedet/common/cedet hides /usr/share/emacs/23.1.92/lisp/cedet/cedet
/usr/share/emacs/site-lisp/cedet/common/cedet-idutils hides /usr/share/emacs/23.1.92/lisp/cedet/cedet-idutils
/usr/share/emacs/site-lisp/cedet/common/cedet-global hides /usr/share/emacs/23.1.92/lisp/cedet/cedet-global

Features:
(shadow sort mail-extr message idna sendmail ecomplete rfc822 mml
mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse
rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util
netrc time-date mm-util mail-prsvr gmm-utils mailheader canlock sha1
hex-util hashcash mail-utils emacsbug face-remap mb-depth two-column
bookmark pp icicles icicles-mode easy-mmode dired regexp-opt
icicles-cmd2 icicles-cmd1 cus-edit icicles-mcmd icicles-mac icicles-fn
icicles-var icicles-opt edmacro kmacro ffap icicles-face thingatpt
eieio-opt server semantic-el semantic-bovine bovine-debug semantic-debug
color-theme time cus-start cus-load semantic-dep paren avoid rgr-java
help-mode view eim eim-extra icomplete+ icomplete crosshairs
col-highlight vline hl-line+ hl-line hexrgb site-gentoo jde-autoload
ecb-autoloads cedet cedet-contrib-load contrib-loaddefs cogre-load
cogre-loaddefs speedbar-load speedbar-loaddefs ede-load ede-loaddefs
ede-speedbar ede-files ede eieio-speedbar semantic-ia-sb
semantic-analyze semantic-scope semantic-analyze-fcn semantic-sort
semanticdb-el semanticdb-search semantic-find semanticdb semantic-ctxt
semantic-format semantic-util-modes semantic-util semantic semantic-lex
semantic-tag working fame speedbar sb-image ezimage dframe easymenu
assoc eieio-custom wid-edit ede-source eieio-base srecode-load srecode
srecode-loaddefs semantic-load semantic-fw semantic-loaddefs mode-local
find-func derived eieio-load eieio-loaddefs cedet-load cedet-compat
cedet-loaddefs eieio advice help-fns advice-preload byte-opt bytecomp
byte-compile cl cl-19 inversion tex-site auto-loads tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd
fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer
select scroll-bar mldrag mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces
cus-face files text-properties overlay md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote
make-network-process dbusbind font-render-setting gtk x-toolkit x
multi-tty emacs)

Message #8 received at 5616 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: p1ng2h3ng <at> gmail.com
Cc: 5616 <at> debbugs.gnu.org
Subject: Re: 23.1.92;
	`delete-frame' deletes the last frame when emacsclient runs
Date: Sun, 21 Feb 2010 08:35:59 -0500

> when I run `emacs --daemon -Q' and `emacsclient -nc', then if I try `M-x
> delete-frame', emacsclient seems will delete last remaining frame
> without check or remind.
>
> I think it should be mentioned in the manuals, but all I got said emacs
> will not to delete the last frame, even you try `M-x delete-frame'.
>
> So I think at least there is a doc bug, and manuals should mention about
> that.

Thanks, I have made a note of this in the manual.

Message #13 received at 5616 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> stupidchicken.com>, <p1ng2h3ng <at> gmail.com>
Cc: 5616 <at> debbugs.gnu.org
Subject: RE: bug#5616: 23.1.92;
	`delete-frame' deletes the last frame when emacsclient runs
Date: Sun, 21 Feb 2010 08:00:45 -0800

> > when I run `emacs --daemon -Q' and `emacsclient -nc', then 
> > if I try `M-x delete-frame', emacsclient seems will delete
> > last remaining frame without check or remind.
> >
> > I think it should be mentioned in the manuals, but all I 
> > got said emacs will not to delete the last frame, even you
> > try `M-x delete-frame'.
> >
> > So I think at least there is a doc bug, and manuals should 
> > mention about that.
> 
> Thanks, I have made a note of this in the manual.

You did not mention the doc string, but it also needs to be mentioned there,
IMO.

The doc string mentions the corner condition of not deleting the frame if its
minibuffer is used, but it should also mention the general condition that the
frame is not deleted if it is the last (sole) one, except when using emacsclient
etc.

Message #16 received at 5616 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> stupidchicken.com>
Cc: 5616 <at> debbugs.gnu.org
Subject: RE: bug#5616: 23.1.92;
	`delete-frame' deletes the last frame when emacsclient runs
Date: Sun, 21 Feb 2010 11:25:57 -0800

I wonder if `delete-frame' really should act differently in this way for
emacsclient. What's the rationale for this? Was this exceptional behavior an
explicit design decision or just a side effect of some implementation changes
for emacsclient?

It does make sense that there be a way to delete the sole frame when emacsclient
is used. But should `delete-frame' itself do that by default? I wonder.

Until now (Emacs 23), `(delete-frame FRAME)' has always raised an error if there
is only one visible frame. This means that some existing code will expect this
behavior, and it will now be broken.

Such existing code will now need to be modified to test, itself, whether the
frame is the only visible one, something it has always counted on the default
behavior of `delete-frame' to do. Similarly, new code will now need to test for
this special case, if it doesn't want the last frame to disappear when
emacsclient is used.

Programmers who don't immediately think about the emacsclient special case
(which probably means most programmers) are likely to write code that mistakenly
deletes the last frame when emacsclient is used, unless they bother to consult
the new (amended) doc for `delete-frame' (an old function).

`delete-frame' already has an optional FORCE parameter to handle this case
explicitly. And, FWIW, that is how this client/server use case has been handled
in the past. For example, the `gnuserv.el' client/server code calls
`server-edit' when finished with a buffer. And that calls `delete-frame' with a
non-nil FORCE arg, to force deletion for the client/server case. It achieves the
same client/server behavior as Emacs 23, but without changing the default
behavior of `delete-frame'.

IOW, in `gnuserv.el', the code to treat the special case of client/server is
handled in the client/server code itself. The default behavior of `delete-frame'
is unchanged when you use a client+server.

The Emacs 23 code instead puts this behavior change into the default behavior of
`delete-frame' itself: even with no FORCE arg, the frame is deleted if
client+server is used. This means that the default `delete-frame' behavior is
now context-dependent.

This effectively nullifies the usefulness of the normal sole-visible-frame test
by `delete-frame', since calling code must now explicitly test for that itself,
because of the new, exceptional (but default) behavior for the special case.

In effect, we now have an implicit non-nil FORCE arg when client+server is used.

Shouldn't `delete-frame' with null FORCE arg always raise an error, preventing
deletion of the last visible frame? Shouldn't the client/server code just
explicitly call `delete-frame' with a non-nil FORCE to do what it wants?

Just wondering. It seems like not deleting the last frame has always been part
of the definition of `delete-frame'. This new behavior (with emacsclient)
breaks/changes that. Is that really necessary or a good idea?

Message #19 received at 5616 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 5616 <at> debbugs.gnu.org
Subject: Re: bug#5616: 23.1.92;
	`delete-frame' deletes the last frame when emacsclient runs
Date: Sun, 21 Feb 2010 16:34:12 -0500

"Drew Adams" <drew.adams <at> oracle.com> writes:

> I wonder if `delete-frame' really should act differently in this way for
> emacsclient. What's the rationale for this? Was this exceptional behavior an
> explicit design decision or just a side effect of some implementation changes
> for emacsclient?

The normal reason for refusing to delete the last visible frame is that
doing so orphans the Emacs process; this is moot in daemon mode.

> Until now (Emacs 23), `(delete-frame FRAME)' has always raised an
> error if there is only one visible frame. This means that some
> existing code will expect this behavior, and it will now be broken.

This sounds far-fetched.  Unless you can point to a real-life
misbehavior, let's not worry about this.

Message #22 received at 5616 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: cyd <at> stupidchicken.com, 5616 <at> debbugs.gnu.org
Subject: Re: bug#5616: 23.1.92;
	`delete-frame' deletes the last frame when emacsclient runs
Date: Sun, 21 Feb 2010 23:53:23 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Sun, 21 Feb 2010 11:25:57 -0800
> Cc: 5616 <at> debbugs.gnu.org
> 
> I wonder if `delete-frame' really should act differently in this way for
> emacsclient. What's the rationale for this? Was this exceptional behavior an
> explicit design decision or just a side effect of some implementation changes
> for emacsclient?

It's not the behavior of emacsclient, it's the behavior of "emacs --daemon".

Message #25 received at 5616 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: cyd <at> stupidchicken.com, 5616 <at> debbugs.gnu.org
Subject: RE: bug#5616: 23.1.92;
	`delete-frame' deletes the last frame when emacsclient runs
Date: Sun, 21 Feb 2010 14:06:36 -0800

> It's not the behavior of emacsclient, it's the behavior of 
> "emacs --daemon".

Yes, thanks.

Message #28 received at 5616 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> stupidchicken.com>
Cc: 5616 <at> debbugs.gnu.org
Subject: RE: bug#5616: 23.1.92;
	`delete-frame' deletes the last frame when emacsclient runs
Date: Sun, 21 Feb 2010 15:27:42 -0800

> > I wonder if `delete-frame' really should act differently in 
> > this way for emacsclient. What's the rationale for this?
> > Was this exceptional behavior an explicit design decision or
> > just a side effect of some implementation changes for emacsclient?
> 
> The normal reason for refusing to delete the last visible 
> frame is that doing so orphans the Emacs process; this is moot in
> daemon mode.

That in itself is certainly no argument for introducing exceptional behavior -
making the default behavior of `delete-frame' depend on the context (daemon vs
no daemon).

There is nothing wrong with the daemon-mode code deleting the frame even if it
is the only visible one. I already said that that is appropriate, and I
mentioned that previous client/server code (gnuserv.el) did the same thing. But
that is not a reason to change `delete-frame' itself to have an exceptional
behavior when --daemon is used.

Just because one caller of `foo' doesn't need some of the distinctions that
`foo' makes, that doesn't mean that other callers don't need them. Just because
such a distinction is moot for that one caller, that doesn't mean that it is
moot for all callers.

Just because daemon mode doesn't need to prevent deleting the last frame, that
doesn't mean that the right _way_ to have daemon mode obtain that behavior is to
change the behavior of `delete-frame'.

Get the behavior that is appropriate for daemon mode, sure, but don't change
`delete-frame' to do that. That's not necessary, is it? It's just asking for
trouble and complicating things needlessly (Occam's razor).

Simply have the daemon-mode code call `delete-frame' with a FORCE arg - that's
what it's for. Instead of changing `delete-frame' to make it modal, the daemon
code should call (delete-frame FRAME t), not (delete-frame FRAME). Is there some
reason that that cannot be done?

Unless it is unavoidable to do otherwise, `delete-frame' should do what it
always has done, in all contexts. I see no reason to change it. It already
provides an arg to do what is needed.

> > Until now (Emacs 23), `(delete-frame FRAME)' has always raised an
> > error if there is only one visible frame. This means that some
> > existing code will expect this behavior, and it will now be broken.
> 
> This sounds far-fetched.  Unless you can point to a real-life
> misbehavior, let's not worry about this.

It should be obvious. Please read the rest of my mail. It's not just about
breaking existing code. It's also about making future code more complex.

Now, _anyone_ calling `(delete-frame FRAME)' without a FORCE arg will need to
explicitly test whether FRAME is the last visible frame, if they want to raise
the standard error.

That sole-visible-frame test is _already_ made by `delete-frame' itself. But
code can no longer depend on it, because of this change that makes the behavior
now depend on the context (--daemon). When in daemon mode, that test by
`delete-frame' is ignored, but without employing the tool provided for ignoring
it: the FORCE arg.

As to "real-life misbehavior": Yes, this change broke my code, which is why you
got this bug report from Zheng. I have a function that deletes all windows
showing a given buffer. If the window is alone in its frame, and the frame is
not a standalone minibuffer, then the function deletes the frame.

With this change in the behavior of delete-frame', I had to change the code to
also check whether the frame is the only visible one. Not a big deal, obviously,
but yes, this change has broken real code.

More importantly, what for? What is gained in doing things this way? Why not
just call `(delete-frame FRAME t)' when you need that behavior?

Message #31 received at 5616 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: p1ng2h3ng <at> gmail.com
Cc: 5616 <at> debbugs.gnu.org
Subject: Re: bug#5616: 23.1.92;
	`delete-frame' deletes the last frame when emacsclient runs
Date: Tue, 23 Feb 2010 12:48:47 -0500

> when I run `emacs --daemon -Q' and `emacsclient -nc', then if I try `M-x
> delete-frame', emacsclient seems will delete last remaining frame
> without check or remind.

Yes, this is only marginally new: if you have frames on several
displays, then M-x delete-frame will happily delete the last frame of
a given display, as long as there are still frames on some
other display.

So the case of "emacs --daemon" is only new in that the remaining frame
is actually not visible to the user, but is instead used internally by
the "emacs --daemon" code.

The rule for delete-frame should be something like "refuse to delete
a frame if it would result in a dead Emacs process", but admittedly, the
code doesn't really enforce that either.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.