From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 21 05:48:13 2010 Received: (at submit) by debbugs.gnu.org; 21 Feb 2010 10:48:13 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nj9MC-0001vU-Ej for submit@debbugs.gnu.org; Sun, 21 Feb 2010 05:48:13 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nj83p-0000mE-Vb for submit@debbugs.gnu.org; Sun, 21 Feb 2010 04:25:10 -0500 Received: from mail.gnu.org ([199.232.76.166]:60045 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nj83n-0000W6-0z for submit@debbugs.gnu.org; Sun, 21 Feb 2010 04:25:07 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nj83l-0001Gb-0b for submit@debbugs.gnu.org; Sun, 21 Feb 2010 04:25:07 -0500 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on monty-python X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00, FROM_HAS_MIXED_NUMS, NO_REAL_NAME,UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from lists.gnu.org ([199.232.76.165]:42374) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Nj83k-0001GT-Ph for submit@debbugs.gnu.org; Sun, 21 Feb 2010 04:25:04 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nj83k-0004SF-4b for bug-gnu-emacs@gnu.org; Sun, 21 Feb 2010 04:25:04 -0500 Received: from [140.186.70.92] (port=52578 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nj83i-0004QC-J0 for bug-gnu-emacs@gnu.org; Sun, 21 Feb 2010 04:25:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nj83f-0007Io-3O for bug-gnu-emacs@gnu.org; Sun, 21 Feb 2010 04:25:02 -0500 Received: from mail-ew0-f213.google.com ([209.85.219.213]:50388) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nj83e-0007IZ-SU for bug-gnu-emacs@gnu.org; Sun, 21 Feb 2010 04:24:59 -0500 Received: by ewy5 with SMTP id 5so1848838ewy.32 for ; Sun, 21 Feb 2010 01:24:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:to:subject:date :message-id:mime-version:content-type; bh=P8ImcNac3A1f2rIw2HLkco3y2RLdDU7ue17OuSW7/hU=; b=jknrGHlxn4959271s3T8uUp97/00+7zeDF77P4J20c0a61aMq3keeG92XNY1N58BDL 1rg929WLEtKLmW4NnAdUA/+ZebIjpb5q4YFgnY3dyRX61CVjYmEFTi4oX43OXpMvsIkA N4g3D+tvufdgUPu4EyAjxUyPqZtMZntxXBkzM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type; b=vW9amcezXBykO+FBtxYcTYvl3sFGlTiFua6t0fJ38KLh0uCfOWgu1QM70Zx+SP/G32 d+yQExEyQYg3zNBbIKdZXlOLIJN11CC2HonyZXxI/Bfj1beGDlA+bbJjROSYMJdSGcc8 AXQ+k5kb+/UcJS1+f8LfFYSvD9GwgPuUhtYLo= Received: by 10.213.111.18 with SMTP id q18mr694167ebp.39.1266744294385; Sun, 21 Feb 2010 01:24:54 -0800 (PST) Received: from smtp.gmail.com ([123.148.162.113]) by mx.google.com with ESMTPS id 10sm5628829eyd.13.2010.02.21.01.24.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Feb 2010 01:24:53 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Sun, 21 Feb 2010 17:25:09 +0800 From: p1ng2h3ng@gmail.com To: bug-gnu-emacs@gnu.org Subject: 23.1.92; `delete-frame' deletes the last frame when emacsclient runs Date: Sun, 21 Feb 2010 17:25:09 +0800 Message-ID: <87zl33rle2.fsf@dell.pingz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -5.9 (-----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sun, 21 Feb 2010 05:48:10 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.9 (-----) 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 C-x b g C-g i c y C-g e d e l e f r a C-g e m e m e C-g i c y - c o m o c C-x b C-g f a C-x b C-x b C-x b C-g C-x b C-g C-x b C-g C-g C-g b u f g C-a C-k r e p o r 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) From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 21 08:36:07 2010 Received: (at 5616) by debbugs.gnu.org; 21 Feb 2010 13:36:07 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjByh-0004oJ-5G for submit@debbugs.gnu.org; Sun, 21 Feb 2010 08:36:07 -0500 Received: from pantheon-po34.its.yale.edu ([130.132.50.80]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjByf-0004nv-3u for 5616@debbugs.gnu.org; Sun, 21 Feb 2010 08:36:05 -0500 Received: from furry (adsl-99-96-75-7.dsl.wlfrct.sbcglobal.net [99.96.75.7]) (authenticated bits=0) by pantheon-po34.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o1LDZxGS027053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 21 Feb 2010 08:35:59 -0500 Received: by furry (Postfix, from userid 1000) id 24667C05D; Sun, 21 Feb 2010 08:35:59 -0500 (EST) From: Chong Yidong To: p1ng2h3ng@gmail.com Subject: Re: 23.1.92; `delete-frame' deletes the last frame when emacsclient runs Date: Sun, 21 Feb 2010 08:35:59 -0500 Message-ID: <87tytaiudc.fsf@stupidchicken.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 5616 Cc: 5616@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 21 08:36:29 2010 Received: (at control) by debbugs.gnu.org; 21 Feb 2010 13:36:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjBz3-0004og-DY for submit@debbugs.gnu.org; Sun, 21 Feb 2010 08:36:29 -0500 Received: from pantheon-po25.its.yale.edu ([130.132.50.119]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjByq-0004oR-Ik for control@debbugs.gnu.org; Sun, 21 Feb 2010 08:36:28 -0500 Received: from furry (adsl-99-96-75-7.dsl.wlfrct.sbcglobal.net [99.96.75.7]) (authenticated bits=0) by pantheon-po25.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o1LDaBpD019140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 21 Feb 2010 08:36:11 -0500 Received: by furry (Postfix, from userid 1000) id 4D690C05D; Sun, 21 Feb 2010 08:36:11 -0500 (EST) From: Chong Yidong To: control@debbugs.gnu.org Subject: close 5616 Date: Sun, 21 Feb 2010 08:36:11 -0500 Message-ID: <87r5oeiud0.fsf@stupidchicken.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) close 5616 thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 21 11:01:16 2010 Received: (at 5616) by debbugs.gnu.org; 21 Feb 2010 16:01:16 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjEF9-0007XG-OV for submit@debbugs.gnu.org; Sun, 21 Feb 2010 11:01:15 -0500 Received: from rcsinet11.oracle.com ([148.87.113.123]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjEF8-0007X2-NV for 5616@debbugs.gnu.org; Sun, 21 Feb 2010 11:01:15 -0500 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o1LG18DG014331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 21 Feb 2010 16:01:09 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o1LG17qY022772; Sun, 21 Feb 2010 16:01:07 GMT Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 41130411266768038; Sun, 21 Feb 2010 08:00:38 -0800 Received: from dradamslap1 (/141.144.160.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 21 Feb 2010 08:00:38 -0800 From: "Drew Adams" To: "'Chong Yidong'" , References: <87zl33rle2.fsf@dell.pingz> <87tytaiudc.fsf@stupidchicken.com> 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 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acqy/fdc6RafQUjPQMuX3vbFHlzzBQAEJG9w In-Reply-To: <87tytaiudc.fsf@stupidchicken.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4B8158C4.00A3:SCFMA4539814,ss=1,fgs=0 X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 5616 Cc: 5616@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > > 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 21 14:27:56 2010 Received: (at 5616) by debbugs.gnu.org; 21 Feb 2010 19:27:56 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjHT9-0001cx-NH for submit@debbugs.gnu.org; Sun, 21 Feb 2010 14:27:56 -0500 Received: from acsinet12.oracle.com ([141.146.126.234]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjHT8-0001cn-HD for 5616@debbugs.gnu.org; Sun, 21 Feb 2010 14:27:55 -0500 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o1LJRmGw016585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 21 Feb 2010 19:27:49 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o1LJRl49021707; Sun, 21 Feb 2010 19:27:47 GMT Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 41229001266780350; Sun, 21 Feb 2010 11:25:50 -0800 Received: from dradamslap1 (/141.144.160.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 21 Feb 2010 11:25:49 -0800 From: "Drew Adams" To: "'Chong Yidong'" References: <87zl33rle2.fsf@dell.pingz> <87tytaiudc.fsf@stupidchicken.com> 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 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acqy/fdc6RafQUjPQMuX3vbFHlzzBQAEJG9wAAWnQ7A= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4B818934.006E:SCFMA4539814,ss=1,fgs=0 X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 5616 Cc: 5616@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) 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? From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 21 16:34:23 2010 Received: (at 5616) by debbugs.gnu.org; 21 Feb 2010 21:34:23 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjJRW-0003f3-MH for submit@debbugs.gnu.org; Sun, 21 Feb 2010 16:34:22 -0500 Received: from pantheon-po25.its.yale.edu ([130.132.50.119]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjJRR-0003es-1n for 5616@debbugs.gnu.org; Sun, 21 Feb 2010 16:34:21 -0500 Received: from furry (173-14-147-246-NewEngland.hfc.comcastbusiness.net [173.14.147.246]) (authenticated bits=0) by pantheon-po25.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o1LLYCSS029524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 21 Feb 2010 16:34:13 -0500 Received: by furry (Postfix, from userid 1000) id A3B85C05D; Sun, 21 Feb 2010 16:34:12 -0500 (EST) From: Chong Yidong To: "Drew Adams" Subject: Re: bug#5616: 23.1.92; `delete-frame' deletes the last frame when emacsclient runs References: <87zl33rle2.fsf@dell.pingz> <87tytaiudc.fsf@stupidchicken.com> Date: Sun, 21 Feb 2010 16:34:12 -0500 In-Reply-To: (Drew Adams's message of "Sun, 21 Feb 2010 11:25:57 -0800") Message-ID: <87wry6e0iz.fsf@stupidchicken.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 5616 Cc: 5616@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.3 (---) "Drew Adams" 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 21 16:53:45 2010 Received: (at 5616) by debbugs.gnu.org; 21 Feb 2010 21:53:45 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjJkH-0003zH-JK for submit@debbugs.gnu.org; Sun, 21 Feb 2010 16:53:45 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjJkF-0003zC-AH for 5616@debbugs.gnu.org; Sun, 21 Feb 2010 16:53:44 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0KY700D00OOWKZ00@a-mtaout22.012.net.il> for 5616@debbugs.gnu.org; Sun, 21 Feb 2010 23:53:22 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.213.68]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KY70083GOSX28M0@a-mtaout22.012.net.il>; Sun, 21 Feb 2010 23:53:22 +0200 (IST) Date: Sun, 21 Feb 2010 23:53:23 +0200 From: Eli Zaretskii Subject: Re: bug#5616: 23.1.92; `delete-frame' deletes the last frame when emacsclient runs In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83aav2w90s.fsf@gnu.org> References: <87zl33rle2.fsf@dell.pingz> <87tytaiudc.fsf@stupidchicken.com> X-Spam-Score: -1.7 (-) X-Debbugs-Envelope-To: 5616 Cc: cyd@stupidchicken.com, 5616@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.6 (-) > From: "Drew Adams" > Date: Sun, 21 Feb 2010 11:25:57 -0800 > Cc: 5616@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". From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 21 17:06:50 2010 Received: (at 5616) by debbugs.gnu.org; 21 Feb 2010 22:06:50 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjJwv-0004Dl-Po for submit@debbugs.gnu.org; Sun, 21 Feb 2010 17:06:49 -0500 Received: from acsinet11.oracle.com ([141.146.126.233]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjJwu-0004Dc-KG for 5616@debbugs.gnu.org; Sun, 21 Feb 2010 17:06:49 -0500 Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o1LM6gb6000459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 21 Feb 2010 22:06:43 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o1LM6f5D000578; Sun, 21 Feb 2010 22:06:41 GMT Received: from abhmt008.oracle.com by acsmt353.oracle.com with ESMTP id 39410551266789988; Sun, 21 Feb 2010 14:06:28 -0800 Received: from dradamslap1 (/24.5.179.75) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 21 Feb 2010 14:06:28 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" References: <87zl33rle2.fsf@dell.pingz> <87tytaiudc.fsf@stupidchicken.com> <83aav2w90s.fsf@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 Message-ID: <12D80A3FE1564971830F860102B83DA5@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcqzQFR505IcMmTzQwOZi1SzVW5tEgAAca/Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <83aav2w90s.fsf@gnu.org> X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4B81AE72.008E:SCFMA4539814,ss=1,fgs=0 X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 5616 Cc: cyd@stupidchicken.com, 5616@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > It's not the behavior of emacsclient, it's the behavior of > "emacs --daemon". Yes, thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 21 18:29:09 2010 Received: (at 5616) by debbugs.gnu.org; 21 Feb 2010 23:29:09 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjLEa-0005Os-Mw for submit@debbugs.gnu.org; Sun, 21 Feb 2010 18:29:08 -0500 Received: from rcsinet12.oracle.com ([148.87.113.124]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjLEX-0005OX-3u for 5616@debbugs.gnu.org; Sun, 21 Feb 2010 18:29:07 -0500 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o1LNSwXt021224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 21 Feb 2010 23:29:00 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o1LNSvJl027097; Sun, 21 Feb 2010 23:28:58 GMT Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 41356221266794855; Sun, 21 Feb 2010 15:27:35 -0800 Received: from dradamslap1 (/24.5.179.75) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 21 Feb 2010 15:27:34 -0800 From: "Drew Adams" To: "'Chong Yidong'" References: <87zl33rle2.fsf@dell.pingz> <87tytaiudc.fsf@stupidchicken.com> <87wry6e0iz.fsf@stupidchicken.com> 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 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcqzPaQK6ZA9VI1zR5OEzd4HIQqRFAABIK+A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <87wry6e0iz.fsf@stupidchicken.com> X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4B81C1BA.008B:SCFMA4539814,ss=1,fgs=0 X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 5616 Cc: 5616@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > > 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? From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 12:49:09 2010 Received: (at 5616) by debbugs.gnu.org; 23 Feb 2010 17:49:09 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Njyse-0005BU-Df for submit@debbugs.gnu.org; Tue, 23 Feb 2010 12:49:08 -0500 Received: from chene.dit.umontreal.ca ([132.204.246.20]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjysP-0005B3-V4 for 5616@debbugs.gnu.org; Tue, 23 Feb 2010 12:49:06 -0500 Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id o1NHmlkk029788; Tue, 23 Feb 2010 12:48:48 -0500 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id CBEC14000B; Tue, 23 Feb 2010 12:48:47 -0500 (EST) From: Stefan Monnier To: p1ng2h3ng@gmail.com Subject: Re: bug#5616: 23.1.92; `delete-frame' deletes the last frame when emacsclient runs Message-ID: References: <87zl33rle2.fsf@dell.pingz> Date: Tue, 23 Feb 2010 12:48:47 -0500 In-Reply-To: <87zl33rle2.fsf@dell.pingz> (p1ng2h3ng@gmail.com's message of "Sun, 21 Feb 2010 17:25:09 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3475=0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 5616 Cc: 5616@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > 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 From unknown Mon Sep 08 14:46:11 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 24 Mar 2010 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A long time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator