From unknown Sat Jun 21 10:42:35 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#3696 <3696@debbugs.gnu.org> To: bug#3696 <3696@debbugs.gnu.org> Subject: Status: 23.1.50; C-x # quits the frame before buffer-modified confirmation Reply-To: bug#3696 <3696@debbugs.gnu.org> Date: Sat, 21 Jun 2025 17:42:35 +0000 retitle 3696 23.1.50; C-x # quits the frame before buffer-modified confirma= tion reassign 3696 emacs submitter 3696 Teemu Likonen severity 3696 normal thanks From tlikonen@iki.fi Sat Jun 27 11:35:52 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 27 Jun 2009 18:35:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.3 required=4.0 tests=AWL,URIBL_RHS_DOB autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5RIZmKB031155 for ; Sat, 27 Jun 2009 11:35:49 -0700 Received: from mail.gnu.org ([199.232.76.166]:55876 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1MKckd-0001kO-Qx for emacs-pretest-bug@gnu.org; Sat, 27 Jun 2009 14:35:47 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1MKckb-0005vF-Gm for emacs-pretest-bug@gnu.org; Sat, 27 Jun 2009 14:35:47 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:56270 helo=jenni2.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKckb-0005uR-0D for emacs-pretest-bug@gnu.org; Sat, 27 Jun 2009 14:35:45 -0400 Received: from mithlond.arda.local (80.220.180.181) by jenni2.inet.fi (8.5.014) id 49F5CB640236CB25 for emacs-pretest-bug@gnu.org; Sat, 27 Jun 2009 21:35:35 +0300 Received: from dtw by mithlond.arda.local with local (Exim 4.69) (envelope-from ) id 1MKckR-00029d-BX for emacs-pretest-bug@gnu.org; Sat, 27 Jun 2009 21:35:35 +0300 From: Teemu Likonen To: emacs-pretest-bug@gnu.org Subject: 23.1.50; Buffer-modified confirmation goes to wrong frame in daemon mode Date: Sat, 27 Jun 2009 21:35:35 +0300 Message-ID: <87tz21r0co.fsf@iki.fi> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) In daemon/client mode "C-x #" (server-edit) quits too early from its frame and leaves the confirm "Buffer foo modified; kill anyway? (yes or no)" in wrong frame's minibuffer. If there are no other frames the confirm is totally hidden. Steps to reproduce: 1. Start Emacs in daemon mode: emacs -Q --daemon 2. Open an independent Emacs frame: emacsclient -c -n 3. Leave that frame and start to edit a file in client mode: emacsclient -c -- foo 4. Frame opens with buffer/file "foo". Now modify the buffer and type "C-x #" (server-edit). Answer "n" in the question whether to save the file "foo". The frame for file "foo" closes. 5. In the other frame, the one we opened first, has the question Buffer foo modified; kill anyway? (yes or no) in its minibuffer. I think it should have been shown in the frame where buffer "foo" was. Here's an example of weird situation this bug can lead to. Don't close this Emacs daemon session yet. 6. Close all frames. 7. Start editing a file: emacsclient -c -- foo 8. Modify the buffer, leave the buffer with "C-x #" and answer "n" in the question whether to save the file. The frame for file "foo" closes. The confirmation question is invisible because there are no frames to show it. 9. Open new independent frame: emacsclient -c -n 10. The frame opens but its content is empty. Emacs is still waiting for user's input in the minibuffer but the question is invisible. 11. Press any key to skip the question. Now the frame is displayed normally. Buffer "foo" is still in the buffer list. Quite obviously the question "Buffer foo modified; kill anyway? (yes or no)" should be displayed in the frame of the buffer "foo" before closing the frame. In GNU Emacs 23.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.12.12) of 2009-06-27 on mithlond Windowing system distributor `The X.Org Foundation', version 11.0.10402000 configured using `configure '--prefix=/home/dtw/local'' From tlikonen@iki.fi Sat Jun 27 11:58:14 2009 Received: (at control) by emacsbugs.donarmstrong.com; 27 Jun 2009 18:58:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.3 required=4.0 tests=AWL,ONEWORD,VALID_BTS_CONTROL autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5RIw9Ne002255 for ; Sat, 27 Jun 2009 11:58:11 -0700 Received: from mithlond.arda.local (80.220.180.181) by jenni2.inet.fi (8.5.014) id 49F5CB640236DFF0 for control@emacsbugs.donarmstrong.com; Sat, 27 Jun 2009 21:58:09 +0300 Received: from dtw by mithlond.arda.local with local (Exim 4.69) (envelope-from ) id 1MKd6G-0002CD-Oe for control@emacsbugs.donarmstrong.com; Sat, 27 Jun 2009 21:58:08 +0300 From: Teemu Likonen To: control@debbugs.gnu.org Subject: retitle Date: Sat, 27 Jun 2009 21:58:08 +0300 Message-ID: <87prcpqzb3.fsf@iki.fi> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii retitle 3696 23.1.50; C-x # quits the frame before buffer-modified confirmation From cyd@stupidchicken.com Sun Jun 28 20:29:45 2009 Received: (at 3696-done) by emacsbugs.donarmstrong.com; 29 Jun 2009 03:29:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.1 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from pantheon-po31.its.yale.edu (pantheon-po31.its.yale.edu [130.132.50.82]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5T3TgcW016518 for <3696-done@emacsbugs.donarmstrong.com>; Sun, 28 Jun 2009 20:29:43 -0700 Received: from furry (c-71-192-161-14.hsd1.nh.comcast.net [71.192.161.14]) (authenticated bits=0) by pantheon-po31.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id n5T3TZCT011847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 28 Jun 2009 23:29:35 -0400 Received: by furry (Postfix, from userid 1000) id 78856C09B; Sun, 28 Jun 2009 23:29:35 -0400 (EDT) From: Chong Yidong To: Teemu Likonen Cc: 3696-done@debbugs.gnu.org Subject: Re: 23.1.50; Buffer-modified confirmation goes to wrong frame in daemon mode Date: Sun, 28 Jun 2009 23:29:35 -0400 Message-ID: <87eit3zpi8.fsf@stupidchicken.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) > In daemon/client mode "C-x #" (server-edit) quits too early from its > frame and leaves the confirm "Buffer foo modified; kill anyway? (yes or > no)" in wrong frame's minibuffer. > > Quite obviously the question "Buffer foo modified; kill anyway? (yes or > no)" should be displayed in the frame of the buffer "foo" before closing > the frame. I don't see why we need to prompt twice, so in this case it should be OK to suppress the usual kill-buffer prompt. I've checked in a fix for this into the trunk. From tlikonen@iki.fi Sun Jun 28 22:13:51 2009 Received: (at 3696) by emacsbugs.donarmstrong.com; 29 Jun 2009 05:13:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.7 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5T5Dlau002034 for <3696@emacsbugs.donarmstrong.com>; Sun, 28 Jun 2009 22:13:48 -0700 Received: from mithlond.arda.local (80.220.180.181) by kirsi1.inet.fi (8.5.014) id 49F6055A023EC764; Mon, 29 Jun 2009 08:13:44 +0300 Received: from dtw by mithlond.arda.local with local (Exim 4.69) (envelope-from ) id 1ML9BX-0000aY-K0; Mon, 29 Jun 2009 08:13:43 +0300 From: Teemu Likonen To: Chong Yidong Cc: 3696@debbugs.gnu.org Subject: Re: 23.1.50; Buffer-modified confirmation goes to wrong frame in daemon mode In-Reply-To: <87eit3zpi8.fsf@stupidchicken.com> (Chong Yidong's message of "Sun, 28 Jun 2009 23:29:35 -0400") References: <87eit3zpi8.fsf@stupidchicken.com> Date: Mon, 29 Jun 2009 08:13:43 +0300 Message-ID: <87ws6v62rc.fsf@iki.fi> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On 2009-06-28 23:29 (-0400), Chong Yidong wrote: >> In daemon/client mode "C-x #" (server-edit) quits too early from its >> frame and leaves the confirm "Buffer foo modified; kill anyway? (yes >> or no)" in wrong frame's minibuffer. >> >> Quite obviously the question "Buffer foo modified; kill anyway? (yes >> or no)" should be displayed in the frame of the buffer "foo" before >> closing the frame. > > I don't see why we need to prompt twice, so in this case it should be > OK to suppress the usual kill-buffer prompt. I've checked in a fix for > this into the trunk. I like this "prompt only once" behavior with server mode better. Thanks. It seems to work nicely now. From unknown Sat Jun 21 10:42:35 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: $requester Subject: Internal Control Message-Id: bug archived. Date: Mon, 27 Jul 2009 14:24:10 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A log 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