From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: "Roland Winkler" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 May 2015 19:36:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 20538@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.143120015920828 (code B ref -1); Sat, 09 May 2015 19:36:03 +0000 Received: (at submit) by debbugs.gnu.org; 9 May 2015 19:35:59 +0000 Received: from localhost ([127.0.0.1]:39705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YrAXW-0005Ps-5i for submit@debbugs.gnu.org; Sat, 09 May 2015 15:35:58 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37316) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YrAXR-0005Pb-4g for submit@debbugs.gnu.org; Sat, 09 May 2015 15:35:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YrAXL-00039n-1F for submit@debbugs.gnu.org; Sat, 09 May 2015 15:35:47 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:47732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrAXK-00039j-VZ for submit@debbugs.gnu.org; Sat, 09 May 2015 15:35:46 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrAXK-0001bj-6Q for bug-gnu-emacs@gnu.org; Sat, 09 May 2015 15:35:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YrAXI-00038m-1x for bug-gnu-emacs@gnu.org; Sat, 09 May 2015 15:35:46 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrAXH-00038c-VA for bug-gnu-emacs@gnu.org; Sat, 09 May 2015 15:35:43 -0400 Received: from [2602:30a:2e52:d720:e00c:c376:ae5f:fe40] (port=51066 helo=regnitz) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1YrAXH-0002uk-85 for bug-gnu-emacs@gnu.org; Sat, 09 May 2015 15:35:43 -0400 Date: Sat, 09 May 2015 14:35:40 -0500 Message-Id: <874mnly25v.fsf@gnu.org> From: "Roland Winkler" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) I do not know how I got into this (sorry, I do not have a recipe to reproduce this either). I have a frame I want to delete by running delete-frame. Yet this only gives me the error message "Attempt to delete a surrogate minibuffer frame" and delete-frame refuses to do its job. What does this mean? If nothing else, Emacs could do a better job explaining to the user what it believes is going on and how the user can possibly resolve this. Possibly a relevant detail: I like to run Ediff sessions with one split frame showing both buffers I need to compare. Yet Ediff sometimes comes up with its own ideas about resources it likes to use, grabbing another frame to show each buffer in a separate frame. If I remember correctly this happened here, too, that is, maybe Emacs believes that the frame I want to delete was/is part of the Ediff session. PS: Neither the Emacs nor the Elisp manual mention "surrogate" in any context. In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2) of 2014-10-26 on regnitz Windowing system distributor `The X.Org Foundation', version 11.0.11103000 System Description: Ubuntu 12.04.5 LTS Important settings: value of $LC_COLLATE: C value of $LANG: en_US.ISO-8859-15 locale-coding-system: iso-latin-9-unix From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 May 2015 02:41:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Roland Winkler Cc: 20538@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.143122565727600 (code B ref 20538); Sun, 10 May 2015 02:41:03 +0000 Received: (at 20538) by debbugs.gnu.org; 10 May 2015 02:40:57 +0000 Received: from localhost ([127.0.0.1]:39790 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YrHAm-0007B5-0F for submit@debbugs.gnu.org; Sat, 09 May 2015 22:40:56 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:39647) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YrHAi-0007Ap-GW for 20538@debbugs.gnu.org; Sat, 09 May 2015 22:40:53 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NO400L004H1FX00@a-mtaout23.012.net.il> for 20538@debbugs.gnu.org; Sun, 10 May 2015 05:40:45 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NO400LBY4RXCK60@a-mtaout23.012.net.il>; Sun, 10 May 2015 05:40:45 +0300 (IDT) Date: Sun, 10 May 2015 05:41:03 +0300 From: Eli Zaretskii In-reply-to: <874mnly25v.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83egmpnohs.fsf@gnu.org> References: <874mnly25v.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 09 May 2015 14:35:40 -0500 > From: "Roland Winkler" > > > I do not know how I got into this (sorry, I do not have a recipe to > reproduce this either). I have a frame I want to delete by running > delete-frame. Yet this only gives me the error message > > "Attempt to delete a surrogate minibuffer frame" > > and delete-frame refuses to do its job. What does this mean? It means you tried to delete a frame that serves as a minibuffer for another frame. From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 May 2015 12:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Roland Winkler , 20538@debbugs.gnu.org Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.143126105129053 (code B ref 20538); Sun, 10 May 2015 12:31:02 +0000 Received: (at 20538) by debbugs.gnu.org; 10 May 2015 12:30:51 +0000 Received: from localhost ([127.0.0.1]:39914 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YrQNe-0007YW-AH for submit@debbugs.gnu.org; Sun, 10 May 2015 08:30:50 -0400 Received: from mout.gmx.net ([212.227.17.20]:57349) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YrQNa-0007YD-IN for 20538@debbugs.gnu.org; Sun, 10 May 2015 08:30:47 -0400 Received: from [194.166.83.72] ([194.166.83.72]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M1AIu-1Z6srP2WM4-00tC1c; Sun, 10 May 2015 14:30:39 +0200 Message-ID: <554F4F64.20604@gmx.at> Date: Sun, 10 May 2015 14:30:28 +0200 From: martin rudalics MIME-Version: 1.0 References: <874mnly25v.fsf@gnu.org> In-Reply-To: <874mnly25v.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0v8bn0VqS3u9m/6G152RYjgPyj9GQCK8IlKnQWs4275K5dPFWRH wVDWNN6Qcmmu8LkHxE3Hj+AsbK8hDZnNZFJTrv/GRFVw0zmCr03moL7cuomFodiwGlV8a9y Y0R0Ifp6jqgKo9LnqNrR2pqhAHwudI3b60lKUwCcd5ND5fs8wLGeS18IeeaJoKxUh2/jHXq fNHYx3amdQe2cQtW6E+8A== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > I do not know how I got into this (sorry, I do not have a recipe to > reproduce this either). I have a frame I want to delete by running > delete-frame. Yet this only gives me the error message > > "Attempt to delete a surrogate minibuffer frame" > > and delete-frame refuses to do its job. What does this mean? If > nothing else, Emacs could do a better job explaining to the user > what it believes is going on and how the user can possibly resolve > this. > > Possibly a relevant detail: I like to run Ediff sessions with one > split frame showing both buffers I need to compare. Yet Ediff > sometimes comes up with its own ideas about resources it likes to > use, grabbing another frame to show each buffer in a separate frame. > If I remember correctly this happened here, too, that is, maybe > Emacs believes that the frame I want to delete was/is part of the > Ediff session. It probably happens because ediff (by default) display the "control panel" in a frame without minibuffer and Emacs doesn't allow to make such a frame the last remaining one. I use (custom-set-variables '(ediff-window-setup-function (quote ediff-setup-windows-plain))) which avoids that the control panel appears on a separate frame. martin From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: "Roland Winkler" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 May 2015 19:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 20538@debbugs.gnu.org Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.14312872234285 (code B ref 20538); Sun, 10 May 2015 19:48:02 +0000 Received: (at 20538) by debbugs.gnu.org; 10 May 2015 19:47:03 +0000 Received: from localhost ([127.0.0.1]:40239 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YrXBn-000172-5A for submit@debbugs.gnu.org; Sun, 10 May 2015 15:47:03 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:58941 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YrXBj-00016c-Mj for 20538@debbugs.gnu.org; Sun, 10 May 2015 15:47:00 -0400 Received: from [2602:30a:2e52:d720:e00c:c376:ae5f:fe40] (port=53445 helo=regnitz) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1YrXBi-0005uW-OP; Sun, 10 May 2015 15:46:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <46510.69799.372989.21839@gargle.gargle.HOWL> Date: Sun, 10 May 2015 14:46:54 -0500 From: "Roland Winkler" In-Reply-To: <554F4F64.20604@gmx.at> References: <874mnly25v.fsf@gnu.org> <554F4F64.20604@gmx.at> X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) On Sun May 10 2015 martin rudalics wrote: > It probably happens because ediff (by default) display the "control > panel" in a frame without minibuffer and Emacs doesn't allow to make > such a frame the last remaining one. Not exactly. In the meanwhile, I noticed that the bug can be reproduced as follows: emacs -Q foo bar M-x ediff-buffers ; to compare buffers foo and bar ; select buffer foo C-x 5 2 ; display buffer foo in a 2nd window in new frame ; in the frame displaying buffers foo and bar M-x delete-frame Error: Attempt to delete a surrogate minibuffer frame ; select the frame displaying the Ediff control panel M-x delete-frame Success! It seems this should be the other way round: the "surrogate minibuffer attribute" should be given to the frame displaying the Ediff control panel instead of the frame displaying buffers foo and bar. From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 May 2015 20:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Roland Winkler , martin rudalics Cc: 20538@debbugs.gnu.org Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.14312890727200 (code B ref 20538); Sun, 10 May 2015 20:18:02 +0000 Received: (at 20538) by debbugs.gnu.org; 10 May 2015 20:17:52 +0000 Received: from localhost ([127.0.0.1]:40244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YrXfc-0001s3-2L for submit@debbugs.gnu.org; Sun, 10 May 2015 16:17:52 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:38522) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YrXfZ-0001rq-JM for 20538@debbugs.gnu.org; Sun, 10 May 2015 16:17:50 -0400 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4AKHh7x009013 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 10 May 2015 20:17:43 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t4AKHgZ8018455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 10 May 2015 20:17:42 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t4AKHgsS022366; Sun, 10 May 2015 20:17:42 GMT MIME-Version: 1.0 Message-ID: <0efbad77-3f61-46d9-8092-5db1bec27c3b@default> Date: Sun, 10 May 2015 13:17:43 -0700 (PDT) From: Drew Adams References: <874mnly25v.fsf@gnu.org> <554F4F64.20604@gmx.at> <46510.69799.372989.21839@gargle.gargle.HOWL> In-Reply-To: <46510.69799.372989.21839@gargle.gargle.HOWL> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > emacs -Q foo bar > M-x ediff-buffers ; to compare buffers foo and bar > ; select buffer foo >=20 > C-x 5 2 ; display buffer foo in a 2nd window in new frame I was going to guess that it had something to do with having one of the compared buffers in a separate frame, i.e., two frames showing a buffer being compared. That's been problematic all along, AFAIK. It can make Ediff tremble in the knees. Especially if you do something like this: > M-x delete-frame That kind of thing can also result in Ediff screaming that you've killed one of its relatives. From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2015 03:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Roland Winkler" Cc: martin rudalics , 20538@debbugs.gnu.org Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.143131484516986 (code B ref 20538); Mon, 11 May 2015 03:28:02 +0000 Received: (at 20538) by debbugs.gnu.org; 11 May 2015 03:27:25 +0000 Received: from localhost ([127.0.0.1]:40377 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YreNI-0004Pt-E2 for submit@debbugs.gnu.org; Sun, 10 May 2015 23:27:24 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:32181) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YreNF-0004PV-FO for 20538@debbugs.gnu.org; Sun, 10 May 2015 23:27:22 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCws0EhQYDSSIE6IRjBsGTAMBAoM+AwMEAQcCAQEBg1wEo2OEWA X-IPAS-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCws0EhQYDSSIE6IRjBsGTAMBAoM+AwMEAQcCAQEBg1wEo2OEWA X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="119109309" Received: from 69-165-139-108.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([69.165.139.108]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 May 2015 23:27:15 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 90FACAE36F; Sun, 10 May 2015 23:27:15 -0400 (EDT) From: Stefan Monnier Message-ID: References: <874mnly25v.fsf@gnu.org> <554F4F64.20604@gmx.at> <46510.69799.372989.21839@gargle.gargle.HOWL> Date: Sun, 10 May 2015 23:27:15 -0400 In-Reply-To: <46510.69799.372989.21839@gargle.gargle.HOWL> (Roland Winkler's message of "Sun, 10 May 2015 14:46:54 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > It seems this should be the other way round: the "surrogate > minibuffer attribute" should be given to the frame displaying the > Ediff control panel instead of the frame displaying buffers foo and bar. Putting "surrogate minibuffer attribute" on a frame which doesn't even have a minibuffer wouldn't make much sense. But I guess it would make sense to indicate that this ediff-control frame is kind of "secondary" or "transient" or "deletable if its minibuffer disappears". Maybe we could solve this one with a kind of delete-window-hook similar to kill-buffer-hook, so ediff could use this hook to auto-delete the ediff-control frame when you delete the other windows. Stefan From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2015 10:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Roland Winkler Cc: 20538@debbugs.gnu.org Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.14313389325023 (code B ref 20538); Mon, 11 May 2015 10:09:02 +0000 Received: (at 20538) by debbugs.gnu.org; 11 May 2015 10:08:52 +0000 Received: from localhost ([127.0.0.1]:40588 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yrkdn-0001Ix-Pa for submit@debbugs.gnu.org; Mon, 11 May 2015 06:08:52 -0400 Received: from mout.gmx.net ([212.227.17.20]:62032) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yrkdk-0001Ii-W1 for 20538@debbugs.gnu.org; Mon, 11 May 2015 06:08:49 -0400 Received: from [88.117.58.212] ([88.117.58.212]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M8ZtH-1Z5p7K3LZT-00wDOK; Mon, 11 May 2015 12:08:41 +0200 Message-ID: <55507FA7.7020906@gmx.at> Date: Mon, 11 May 2015 12:08:39 +0200 From: martin rudalics MIME-Version: 1.0 References: <874mnly25v.fsf@gnu.org> <554F4F64.20604@gmx.at> <46510.69799.372989.21839@gargle.gargle.HOWL> In-Reply-To: <46510.69799.372989.21839@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:n4H7QS69T3LbHvjS6z1YgUMeAOo63XfkI5ae/euf8r4iFZuy4bO yKoffvi2ivXYzPsCZBn41Ofgew9qp5jTFJNfeMAs/zlA18ypFlkU2Yx8OxTgGrKKWJLGT4D DN68z4qlzF8zbe9GH2MIJ9SpSs2OYOU0SMVRluUvgoNmM4eWBf9hvmNjUnIl0Seank0kMAW GGJBSxoxxqZxDMIjNytzA== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> It probably happens because ediff (by default) display the "control >> panel" in a frame without minibuffer and Emacs doesn't allow to make >> such a frame the last remaining one. > > Not exactly. > > In the meanwhile, I noticed that the bug can be reproduced as > follows: > > emacs -Q foo bar > > M-x ediff-buffers ; to compare buffers foo and bar > > ; select buffer foo > > C-x 5 2 ; display buffer foo in a 2nd window in new frame > > ; in the frame displaying buffers foo and bar > > M-x delete-frame > > Error: Attempt to delete a surrogate minibuffer frame Because the "frame displaying buffers foo and bar" is the frame that has the minibuffer for the minibuffer-less "frame displaying the Ediff control panel". As I said above you are not allowed to delete the frame with the minibuffer because that would make the minibuffer-less frame the last remaining one. > ; select the frame displaying the Ediff control panel > > M-x delete-frame > > Success! That frame has no minibuffer. Hence it cannot possibly serve as surrogate minibuffer frame and you can delete it without any problems. > It seems this should be the other way round: the "surrogate > minibuffer attribute" should be given to the frame displaying the > Ediff control panel instead of the frame displaying buffers foo and bar. The surrogate minibuffer frame is the one whose minibuffer substitutes the non-existing minibuffer of the control panel frame. This is how ediff sets things up. martin From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: "Roland Winkler" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2015 17:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 20538@debbugs.gnu.org Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.143136380217567 (code B ref 20538); Mon, 11 May 2015 17:04:02 +0000 Received: (at 20538) by debbugs.gnu.org; 11 May 2015 17:03:22 +0000 Received: from localhost ([127.0.0.1]:41198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yrr6w-0004ZH-AG for submit@debbugs.gnu.org; Mon, 11 May 2015 13:03:22 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:60038 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yrr6t-0004Z8-HO for 20538@debbugs.gnu.org; Mon, 11 May 2015 13:03:20 -0400 Received: from [131.156.157.22] (port=56939 helo=lukas) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1Yrr6t-0005m2-09; Mon, 11 May 2015 13:03:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <57556.25510.62959.21840@gargle.gargle.HOWL> Date: Mon, 11 May 2015 12:03:16 -0500 From: "Roland Winkler" In-Reply-To: <55507FA7.7020906@gmx.at> References: <874mnly25v.fsf@gnu.org> <554F4F64.20604@gmx.at> <46510.69799.372989.21839@gargle.gargle.HOWL> <55507FA7.7020906@gmx.at> X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) On Mon May 11 2015 martin rudalics wrote: > Because the "frame displaying buffers foo and bar" is the frame that has > the minibuffer for the minibuffer-less "frame displaying the Ediff > control panel". As I said above you are not allowed to delete the frame > with the minibuffer because that would make the minibuffer-less frame > the last remaining one. > > > ; select the frame displaying the Ediff control panel > > > > M-x delete-frame > > > > Success! > > That frame has no minibuffer. Hence it cannot possibly serve as > surrogate minibuffer frame and you can delete it without any problems. > > > It seems this should be the other way round: the "surrogate > > minibuffer attribute" should be given to the frame displaying the > > Ediff control panel instead of the frame displaying buffers foo and bar. > > The surrogate minibuffer frame is the one whose minibuffer substitutes > the non-existing minibuffer of the control panel frame. This is how > ediff sets things up. I see, thank you, initially I was rather off with my interpretation of what was happening. My usage scenario is the following: Normally I run emacs with always no more than two frames. I create a 2nd frame as needed, but I delete it when it is not needed anymore so that it does not clutter the desktop. An ediff session then adds one more frame for the ediff control panel. Yet during an ediff session I can get side-tracked: the frame used for displaying the ediff buffers A and B may get used for something else, then I create another frame and finally I want to delete the frame that Ediff wants to use as surrogate minibuffer frame. I understand that the frame displaying the ediff control panel needs *some* other frame to provide a minibuffer. Is it necessary that a particular frame serves this purpose? Or would it be sufficient that emacs made sure that always at least one frame has a proper minibuffer? (In the case of the ediff control panel, I believe it is fair to assume that anyway this frame rarely requires a proper minibuffer. For me, the control panel is effectively the minibuffer for an ediff session: commands are entered in that buffer; there is no need for "a minibuffer for the ediff minibuffer".) If nothing else, it would be good if the error message issued when attempting to delete a surrogate minibuffer frame could be improved: I got this error message at a point when I was not thinking about ediff, but I just wanted to get back to my default "one frame setup"; and it happened I wanted to delete the wrong frame to achieve this goal. Roland From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 May 2015 09:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Roland Winkler Cc: 20538@debbugs.gnu.org Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.143142339727280 (code B ref 20538); Tue, 12 May 2015 09:37:02 +0000 Received: (at 20538) by debbugs.gnu.org; 12 May 2015 09:36:37 +0000 Received: from localhost ([127.0.0.1]:41646 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ys6c8-00075w-Pt for submit@debbugs.gnu.org; Tue, 12 May 2015 05:36:37 -0400 Received: from mout.gmx.net ([212.227.15.19]:49295) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ys6c6-00075g-Af for 20538@debbugs.gnu.org; Tue, 12 May 2015 05:36:35 -0400 Received: from [62.47.248.4] ([62.47.248.4]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LZzKf-1Zd1Dl0dbR-00lnvu; Tue, 12 May 2015 11:36:28 +0200 Message-ID: <5551C998.4040508@gmx.at> Date: Tue, 12 May 2015 11:36:24 +0200 From: martin rudalics MIME-Version: 1.0 References: <874mnly25v.fsf@gnu.org> <554F4F64.20604@gmx.at> <46510.69799.372989.21839@gargle.gargle.HOWL> <55507FA7.7020906@gmx.at> <57556.25510.62959.21840@gargle.gargle.HOWL> In-Reply-To: <57556.25510.62959.21840@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:2R+NVvqMChAupPosxkPepQm4uZRiN5GJEGJFfBdqPaQ9+eXJSAB v1F89vnYIL56zXDulizJJeVj9qmiAPCnaqwuy19T2JQUmCrPMmuiEAcjI9cVll8yIAZEQq1 qEnvAoCuPB5flmuJp1Iz+5HR+TSOPSQzKjYViHj7KnyLICRr9ht1WqMRlp8dskljFDYC4mW aNoOxkxLlMRddwSu9VIMg== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > My usage scenario is the following: > > Normally I run emacs with always no more than two frames. I create > a 2nd frame as needed, but I delete it when it is not needed anymore > so that it does not clutter the desktop. An ediff session then adds > one more frame for the ediff control panel. Yet during an ediff > session I can get side-tracked: the frame used for displaying the ediff > buffers A and B may get used for something else, then I create > another frame and finally I want to delete the frame that Ediff > wants to use as surrogate minibuffer frame. Such things happen to me all the time. That's why I prefer `ediff-setup-windows-plain' (and `split-window-horizontally' as `ediff-split-window-function'). > I understand that the frame displaying the ediff control panel needs > *some* other frame to provide a minibuffer. Is it necessary that a > particular frame serves this purpose? Or would it be sufficient > that emacs made sure that always at least one frame has a proper > minibuffer? (In the case of the ediff control panel, I believe it > is fair to assume that anyway this frame rarely requires a proper > minibuffer. For me, the control panel is effectively the minibuffer > for an ediff session: commands are entered in that buffer; there is > no need for "a minibuffer for the ediff minibuffer".) At any time every frame has a corresponding minibuffer window and that window won't change for the frame's entire lifetime. > If nothing else, it would be good if the error message issued when > attempting to delete a surrogate minibuffer frame could be improved: > I got this error message at a point when I was not thinking about > ediff, but I just wanted to get back to my default "one frame > setup"; and it happened I wanted to delete the wrong frame to > achieve this goal. The problem is that the entity that issues the message is not aware of the intrinsics of ediff. martin From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: "Roland Winkler" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 May 2015 19:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 20538@debbugs.gnu.org Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.143145976117501 (code B ref 20538); Tue, 12 May 2015 19:43:01 +0000 Received: (at 20538) by debbugs.gnu.org; 12 May 2015 19:42:41 +0000 Received: from localhost ([127.0.0.1]:42686 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsG4f-0004YD-5G for submit@debbugs.gnu.org; Tue, 12 May 2015 15:42:41 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:32813 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsG4c-0004Y5-Q8 for 20538@debbugs.gnu.org; Tue, 12 May 2015 15:42:39 -0400 Received: from [131.156.157.22] (port=51529 helo=lukas) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1YsG4c-0002JX-AI; Tue, 12 May 2015 15:42:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22444.26522.862962.21842@gargle.gargle.HOWL> Date: Tue, 12 May 2015 14:42:36 -0500 From: "Roland Winkler" In-Reply-To: <5551C998.4040508@gmx.at> References: <874mnly25v.fsf@gnu.org> <554F4F64.20604@gmx.at> <46510.69799.372989.21839@gargle.gargle.HOWL> <55507FA7.7020906@gmx.at> <57556.25510.62959.21840@gargle.gargle.HOWL> <5551C998.4040508@gmx.at> X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) On Tue May 12 2015 martin rudalics wrote: > Such things happen to me all the time. That's why I prefer > `ediff-setup-windows-plain' (and `split-window-horizontally' as > `ediff-split-window-function'). How do you use the undocumented function ediff-setup-windows-plain? (Could this usage be properly documented?) > The problem is that the entity that issues the message is not aware of > the intrinsics of ediff. Sure. I was more thinking that quite generally the error message talking about a "surrogate minibuffer frame" is a bit confusing if one has no clue what this term means. When I first saw this message, I thought of something like a "minibuffer frame" that was some kind of surrogate (which was why I thought this was supposed to refer to the Ediff control panel that acts like a minibuffer for an ediff session). Perhaps the error message could be changed to something like "Attempt to delete frame with a surrogate minibuffer for frame XYZ" From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 May 2015 07:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Roland Winkler Cc: 20538@debbugs.gnu.org Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.143150234610876 (code B ref 20538); Wed, 13 May 2015 07:33:02 +0000 Received: (at 20538) by debbugs.gnu.org; 13 May 2015 07:32:26 +0000 Received: from localhost ([127.0.0.1]:42989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsR9V-0002pL-QB for submit@debbugs.gnu.org; Wed, 13 May 2015 03:32:26 -0400 Received: from mout.gmx.net ([212.227.15.15]:54939) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsR9T-0002pA-LB for 20538@debbugs.gnu.org; Wed, 13 May 2015 03:32:24 -0400 Received: from [188.22.104.219] ([188.22.104.219]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LanoO-1ZcSDp0CEK-00kO2v; Wed, 13 May 2015 09:32:17 +0200 Message-ID: <5552FDFB.8080500@gmx.at> Date: Wed, 13 May 2015 09:32:11 +0200 From: martin rudalics MIME-Version: 1.0 References: <874mnly25v.fsf@gnu.org> <554F4F64.20604@gmx.at> <46510.69799.372989.21839@gargle.gargle.HOWL> <55507FA7.7020906@gmx.at> <57556.25510.62959.21840@gargle.gargle.HOWL> <5551C998.4040508@gmx.at> <22444.26522.862962.21842@gargle.gargle.HOWL> In-Reply-To: <22444.26522.862962.21842@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:jaVF3xLeX30kqkSOyI31ACZ0YpzdkPRVXjGl7wiK97q77QUK925 eZGBxBl8FIH5ngNr3Vco9Db9hFzPBmir0Nyq6GjDqFtTFnLJdj5UoF+CwKcvF/7f9Tzozm5 Dt/NSSDO5mYCpccotA2n2oKzmp8JugpoCryOf5yiNlHoGfeU0KEJafknE8o6i/lrDgRDuO1 PVpAJnPo5bxDSp8kgjKog== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > How do you use the undocumented function ediff-setup-windows-plain? > (Could this usage be properly documented?) It's an option (a customizable variable). Do M-: (require 'ediff) RET C-h v RET ediff-window-setup-function RET > Sure. I was more thinking that quite generally the error message > talking about a "surrogate minibuffer frame" is a bit confusing if > one has no clue what this term means. When I first saw this > message, I thought of something like a "minibuffer frame" that was > some kind of surrogate (which was why I thought this was supposed to > refer to the Ediff control panel that acts like a minibuffer for an > ediff session). > > Perhaps the error message could be changed to something like > > "Attempt to delete frame with a surrogate minibuffer for frame XYZ" Maybe we should say in the documentation of `delete-frame' something like A frame may not be deleted if its minibuffer serves as surrogate minibuffer for another frame. martin From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: "Roland Winkler" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 May 2015 15:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 20538@debbugs.gnu.org Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.14315298803021 (code B ref 20538); Wed, 13 May 2015 15:12:02 +0000 Received: (at 20538) by debbugs.gnu.org; 13 May 2015 15:11:20 +0000 Received: from localhost ([127.0.0.1]:43912 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsYJb-0000ma-30 for submit@debbugs.gnu.org; Wed, 13 May 2015 11:11:19 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:33536 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsYJU-0000mF-B1 for 20538@debbugs.gnu.org; Wed, 13 May 2015 11:11:17 -0400 Received: from [131.156.157.22] (port=52043 helo=lukas) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1YsYJT-00061n-K9; Wed, 13 May 2015 11:11:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <27022.80056.898164.21843@gargle.gargle.HOWL> Date: Wed, 13 May 2015 10:11:10 -0500 From: "Roland Winkler" In-Reply-To: <5552FDFB.8080500@gmx.at> References: <874mnly25v.fsf@gnu.org> <554F4F64.20604@gmx.at> <46510.69799.372989.21839@gargle.gargle.HOWL> <55507FA7.7020906@gmx.at> <57556.25510.62959.21840@gargle.gargle.HOWL> <5551C998.4040508@gmx.at> <22444.26522.862962.21842@gargle.gargle.HOWL> <5552FDFB.8080500@gmx.at> X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) On Wed May 13 2015 martin rudalics wrote: > > How do you use the undocumented function ediff-setup-windows-plain? > > (Could this usage be properly documented?) > > It's an option (a customizable variable). Do > > M-: (require 'ediff) RET > > C-h v RET ediff-window-setup-function RET Thanks - so the option is ediff-window-setup-function. I suggest to give the function ediff-setup-windows-plain a docstring like Set up windows for Ediff in one frame. Useful as value for `ediff-window-setup-function'. Then your previous email telling me only about the function ediff-setup-windows-plain gives an ignorant user like myself already all the info he needs. > > Perhaps the error message could be changed to something like > > > > "Attempt to delete frame with a surrogate minibuffer for frame XYZ" Is the problem with the above that frames do not have selfexplanatory unique names? Oh well, too bad. > Maybe we should say in the documentation of `delete-frame' something > like > > A frame may not be deleted if its minibuffer serves as surrogate > minibuffer for another frame. Yes, thanks, that would be better than the current phrase. If the buzzword "surrogate" appears also in the corresponding section of the elisp manual, I might have never started this thread. Roland From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 10:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Roland Winkler Cc: 20538@debbugs.gnu.org Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.143159844112355 (code B ref 20538); Thu, 14 May 2015 10:14:02 +0000 Received: (at 20538) by debbugs.gnu.org; 14 May 2015 10:14:01 +0000 Received: from localhost ([127.0.0.1]:44451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ysq9R-0003DC-0u for submit@debbugs.gnu.org; Thu, 14 May 2015 06:14:01 -0400 Received: from mout.gmx.net ([212.227.17.20]:57061) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ysq9O-0003Cu-VB for 20538@debbugs.gnu.org; Thu, 14 May 2015 06:13:59 -0400 Received: from [178.190.18.121] ([178.190.18.121]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M6zvN-1Z5GEf44KD-00wkic; Thu, 14 May 2015 12:13:53 +0200 Message-ID: <5554755A.3060609@gmx.at> Date: Thu, 14 May 2015 12:13:46 +0200 From: martin rudalics MIME-Version: 1.0 References: <874mnly25v.fsf@gnu.org> <554F4F64.20604@gmx.at> <46510.69799.372989.21839@gargle.gargle.HOWL> <55507FA7.7020906@gmx.at> <57556.25510.62959.21840@gargle.gargle.HOWL> <5551C998.4040508@gmx.at> <22444.26522.862962.21842@gargle.gargle.HOWL> <5552FDFB.8080500@gmx.at> <27022.80056.898164.21843@gargle.gargle.HOWL> In-Reply-To: <27022.80056.898164.21843@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:P5d1tv6ix33UJT7sqlVTbsqTRBUllwvJ6+HTzbyhCYUE9hQRSYp J4S/380W7NZq/mfcZHENvH2baVBgJOvLqgiRnbf8gHakjrd22OZPLI0prx3/sQFYDh4YNy3 FrKwNPbXa1YidlHtKd4G0/KRpMyEGljPdpMPrqVwPUNLtAf4co3sNzxB3UUj+dzHkYOS4kE ke97FIUuW7EjWMeHVgBBQ== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > Then your previous email telling me only about the function > ediff-setup-windows-plain gives an ignorant user like myself already > all the info he needs. Well, in my first mail in this thread I wrote >> I use >> >> (custom-set-variables >> '(ediff-window-setup-function (quote ediff-setup-windows-plain))) >> >> which avoids that the control panel appears on a separate frame. Hence I thought you would be already aware of the real nature of `ediff-setup-windows-plain' ;-) >> > Perhaps the error message could be changed to something like >> > >> > "Attempt to delete frame with a surrogate minibuffer for frame XYZ" > > Is the problem with the above that frames do not have > selfexplanatory unique names? Oh well, too bad. We could use (frame-parameter frame 'name) but it's not unique. >> Maybe we should say in the documentation of `delete-frame' something >> like >> >> A frame may not be deleted if its minibuffer serves as surrogate >> minibuffer for another frame. > > Yes, thanks, that would be better than the current phrase. If the > buzzword "surrogate" appears also in the corresponding section of > the elisp manual, I might have never started this thread. OK. Unless someone has a better idea I'll rewrite it that way. martin From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: "Roland Winkler" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 May 2015 19:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 20538@debbugs.gnu.org Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.143180376615107 (code B ref 20538); Sat, 16 May 2015 19:17:02 +0000 Received: (at 20538) by debbugs.gnu.org; 16 May 2015 19:16:06 +0000 Received: from localhost ([127.0.0.1]:47490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YthZ7-0003va-OH for submit@debbugs.gnu.org; Sat, 16 May 2015 15:16:06 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:51702 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YthZ5-0003vR-DU for 20538@debbugs.gnu.org; Sat, 16 May 2015 15:16:03 -0400 Received: from [2602:30a:2e52:d720:4922:1e99:949:cdf] (port=49509 helo=regnitz) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1YthZ4-0004bY-O1; Sat, 16 May 2015 15:16:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38768.58391.947692.21847@gargle.gargle.HOWL> Date: Sat, 16 May 2015 14:16:00 -0500 From: "Roland Winkler" In-Reply-To: <5554755A.3060609@gmx.at> References: <874mnly25v.fsf@gnu.org> <554F4F64.20604@gmx.at> <46510.69799.372989.21839@gargle.gargle.HOWL> <55507FA7.7020906@gmx.at> <57556.25510.62959.21840@gargle.gargle.HOWL> <5551C998.4040508@gmx.at> <22444.26522.862962.21842@gargle.gargle.HOWL> <5552FDFB.8080500@gmx.at> <27022.80056.898164.21843@gargle.gargle.HOWL> <5554755A.3060609@gmx.at> X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) On Thu May 14 2015 martin rudalics wrote: > Hence I thought you would be already aware of the real nature of > `ediff-setup-windows-plain' ;-) I am sorry this slipped through > We could use (frame-parameter frame 'name) but it's not unique. Yes, when the window manager shows the same name for multiple frames, this is not really helpful. Yet there is no simple solution for this. > OK. Unless someone has a better idea I'll rewrite it that way. Thanks, Roland From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 May 2015 09:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Roland Winkler Cc: 20538@debbugs.gnu.org Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.14320285687648 (code B ref 20538); Tue, 19 May 2015 09:43:02 +0000 Received: (at 20538) by debbugs.gnu.org; 19 May 2015 09:42:48 +0000 Received: from localhost ([127.0.0.1]:49616 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yue2x-0001zI-TA for submit@debbugs.gnu.org; Tue, 19 May 2015 05:42:48 -0400 Received: from mout.gmx.net ([212.227.15.15]:56714) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yue2w-0001z3-3B for 20538@debbugs.gnu.org; Tue, 19 May 2015 05:42:46 -0400 Received: from [62.47.248.64] ([62.47.248.64]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MHX0m-1YtY6z3W2e-003L6R; Tue, 19 May 2015 11:42:38 +0200 Message-ID: <555B058A.9040002@gmx.at> Date: Tue, 19 May 2015 11:42:34 +0200 From: martin rudalics MIME-Version: 1.0 References: <874mnly25v.fsf@gnu.org> <554F4F64.20604@gmx.at> <46510.69799.372989.21839@gargle.gargle.HOWL> <55507FA7.7020906@gmx.at> <57556.25510.62959.21840@gargle.gargle.HOWL> <5551C998.4040508@gmx.at> <22444.26522.862962.21842@gargle.gargle.HOWL> <5552FDFB.8080500@gmx.at> <27022.80056.898164.21843@gargle.gargle.HOWL> <5554755A.3060609@gmx.at> In-Reply-To: <5554755A.3060609@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:kaDTDxZ8AXoGNE4Pu1v/yAQqQsW64VX+sxBj8fmt9LpwJiq8hAc 2sn6dV/Zunz4YY7Rwj6j4+fjNdxwMiTDECLGAhOGoTC8C8b+AUdrUwp6xmo1TPujkq59UxW M8pZvI9tfCEeUrbBEDECKcTsXV32kOSEV9umracj4nrwAeERkzVqtOCk1LW/NwShfzJ4PqL /XCR9laEEw7TJ3Wr1SHog== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > > Yes, thanks, that would be better than the current phrase. If the > > buzzword "surrogate" appears also in the corresponding section of > > the elisp manual, I might have never started this thread. I updated the doc-string of `delete-frame' and the corresponding parts of the Elisp manual in commit 448cacc..9a07af0. Please have a look. martin From unknown Mon Jun 23 18:31:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Resent-From: "Roland Winkler" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 May 2015 16:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 20538@debbugs.gnu.org Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.143205197516884 (code B ref 20538); Tue, 19 May 2015 16:13:02 +0000 Received: (at 20538) by debbugs.gnu.org; 19 May 2015 16:12:55 +0000 Received: from localhost ([127.0.0.1]:50314 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yuk8Q-0004OC-OY for submit@debbugs.gnu.org; Tue, 19 May 2015 12:12:55 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:39079 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yuk8K-0004Nx-Uu for 20538@debbugs.gnu.org; Tue, 19 May 2015 12:12:49 -0400 Received: from [131.156.157.22] (port=54356 helo=lukas) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1Yuk8K-0003oc-M5; Tue, 19 May 2015 12:12:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24827.58076.470864.21851@gargle.gargle.HOWL> Date: Tue, 19 May 2015 11:12:43 -0500 From: "Roland Winkler" In-Reply-To: <555B058A.9040002@gmx.at> References: <874mnly25v.fsf@gnu.org> <554F4F64.20604@gmx.at> <46510.69799.372989.21839@gargle.gargle.HOWL> <55507FA7.7020906@gmx.at> <57556.25510.62959.21840@gargle.gargle.HOWL> <5551C998.4040508@gmx.at> <22444.26522.862962.21842@gargle.gargle.HOWL> <5552FDFB.8080500@gmx.at> <27022.80056.898164.21843@gargle.gargle.HOWL> <5554755A.3060609@gmx.at> <555B058A.9040002@gmx.at> X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) On Tue May 19 2015 martin rudalics wrote: > > > Yes, thanks, that would be better than the current phrase. If the > > > buzzword "surrogate" appears also in the corresponding section of > > > the elisp manual, I might have never started this thread. > > I updated the doc-string of `delete-frame' and the corresponding parts > of the Elisp manual in commit 448cacc..9a07af0. Please have a look. Looks fine to me. Info-search "surrogate" in the elisp manual now matches delete-frame. From unknown Mon Jun 23 18:31:39 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: "Roland Winkler" Subject: bug#20538: closed (Re: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame) Message-ID: References: <555C58CD.2080900@gmx.at> <874mnly25v.fsf@gnu.org> X-Gnu-PR-Message: they-closed 20538 X-Gnu-PR-Package: emacs Reply-To: 20538@debbugs.gnu.org Date: Wed, 20 May 2015 09:51:04 +0000 Content-Type: multipart/mixed; boundary="----------=_1432115464-26278-1" This is a multi-part message in MIME format... ------------=_1432115464-26278-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #20538: 24.4; Attempt to delete a surrogate minibuffer frame which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 20538@debbugs.gnu.org. --=20 20538: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D20538 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1432115464-26278-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 20538-done) by debbugs.gnu.org; 20 May 2015 09:50:18 +0000 Received: from localhost ([127.0.0.1]:50723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yv0dl-0006od-DR for submit@debbugs.gnu.org; Wed, 20 May 2015 05:50:17 -0400 Received: from mout.gmx.net ([212.227.17.20]:51048) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yv0dj-0006oO-La for 20538-done@debbugs.gnu.org; Wed, 20 May 2015 05:50:16 -0400 Received: from [178.191.136.40] ([178.191.136.40]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LiHc7-1ZZaaY3V5P-00nRsm; Wed, 20 May 2015 11:50:10 +0200 Message-ID: <555C58CD.2080900@gmx.at> Date: Wed, 20 May 2015 11:50:05 +0200 From: martin rudalics MIME-Version: 1.0 To: Roland Winkler Subject: Re: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame References: <874mnly25v.fsf@gnu.org> <554F4F64.20604@gmx.at> <46510.69799.372989.21839@gargle.gargle.HOWL> <55507FA7.7020906@gmx.at> <57556.25510.62959.21840@gargle.gargle.HOWL> <5551C998.4040508@gmx.at> <22444.26522.862962.21842@gargle.gargle.HOWL> <5552FDFB.8080500@gmx.at> <27022.80056.898164.21843@gargle.gargle.HOWL> <5554755A.3060609@gmx.at> <555B058A.9040002@gmx.at> <24827.58076.470864.21851@gargle.gargle.HOWL> In-Reply-To: <24827.58076.470864.21851@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:S8pi+jm3SKqAts2icgpor935Eo/Ngguebsd46X3uYfoi9dMMFbR WwFO823GaRF6zhviigWILQCQybBARgEmD3yd4wBs4uWAy8hzTAYOBjj6xStsqIB8Q0DHQxg MH7PMP5OSASDuBVpUHSS2XDlwKm+T8xh9y+/2YL6r5T6GCdrE84/0qNfzFzU/+GuIsr9SSz TJgNTAj9CrjgZa8oO63AQ== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 20538-done Cc: 20538-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > Looks fine to me. Info-search "surrogate" in the elisp manual now > matches delete-frame. So I'm closing this bug. Thanks, martin ------------=_1432115464-26278-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 9 May 2015 19:35:59 +0000 Received: from localhost ([127.0.0.1]:39705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YrAXW-0005Ps-5i for submit@debbugs.gnu.org; Sat, 09 May 2015 15:35:58 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37316) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YrAXR-0005Pb-4g for submit@debbugs.gnu.org; Sat, 09 May 2015 15:35:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YrAXL-00039n-1F for submit@debbugs.gnu.org; Sat, 09 May 2015 15:35:47 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:47732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrAXK-00039j-VZ for submit@debbugs.gnu.org; Sat, 09 May 2015 15:35:46 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrAXK-0001bj-6Q for bug-gnu-emacs@gnu.org; Sat, 09 May 2015 15:35:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YrAXI-00038m-1x for bug-gnu-emacs@gnu.org; Sat, 09 May 2015 15:35:46 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrAXH-00038c-VA for bug-gnu-emacs@gnu.org; Sat, 09 May 2015 15:35:43 -0400 Received: from [2602:30a:2e52:d720:e00c:c376:ae5f:fe40] (port=51066 helo=regnitz) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1YrAXH-0002uk-85 for bug-gnu-emacs@gnu.org; Sat, 09 May 2015 15:35:43 -0400 Date: Sat, 09 May 2015 14:35:40 -0500 Message-Id: <874mnly25v.fsf@gnu.org> From: "Roland Winkler" To: bug-gnu-emacs@gnu.org Subject: 24.4; Attempt to delete a surrogate minibuffer frame X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) I do not know how I got into this (sorry, I do not have a recipe to reproduce this either). I have a frame I want to delete by running delete-frame. Yet this only gives me the error message "Attempt to delete a surrogate minibuffer frame" and delete-frame refuses to do its job. What does this mean? If nothing else, Emacs could do a better job explaining to the user what it believes is going on and how the user can possibly resolve this. Possibly a relevant detail: I like to run Ediff sessions with one split frame showing both buffers I need to compare. Yet Ediff sometimes comes up with its own ideas about resources it likes to use, grabbing another frame to show each buffer in a separate frame. If I remember correctly this happened here, too, that is, maybe Emacs believes that the frame I want to delete was/is part of the Ediff session. PS: Neither the Emacs nor the Elisp manual mention "surrogate" in any context. In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2) of 2014-10-26 on regnitz Windowing system distributor `The X.Org Foundation', version 11.0.11103000 System Description: Ubuntu 12.04.5 LTS Important settings: value of $LC_COLLATE: C value of $LANG: en_US.ISO-8859-15 locale-coding-system: iso-latin-9-unix ------------=_1432115464-26278-1--