From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Roland Winkler" Newsgroups: gmane.emacs.bugs Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame Date: Mon, 11 May 2015 12:03:16 -0500 Message-ID: <57556.25510.62959.21840@gargle.gargle.HOWL> References: <874mnly25v.fsf@gnu.org> <554F4F64.20604@gmx.at> <46510.69799.372989.21839@gargle.gargle.HOWL> <55507FA7.7020906@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1431363864 11827 80.91.229.3 (11 May 2015 17:04:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 May 2015 17:04:24 +0000 (UTC) Cc: 20538@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon May 11 19:04:14 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yrr7l-0005Nu-9N for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 May 2015 19:04:13 +0200 Original-Received: from localhost ([::1]:38831 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yrr7k-0007bI-F4 for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 May 2015 13:04:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yrr7g-0007bD-OJ for bug-gnu-emacs@gnu.org; Mon, 11 May 2015 13:04:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yrr7a-0003Dl-KM for bug-gnu-emacs@gnu.org; Mon, 11 May 2015 13:04:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59456) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yrr7a-0003DF-Gm for bug-gnu-emacs@gnu.org; Mon, 11 May 2015 13:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yrr7a-0004aL-2g for bug-gnu-emacs@gnu.org; Mon, 11 May 2015 13:04:02 -0400 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 20538-submit@debbugs.gnu.org id=B20538.143136380217567 (code B ref 20538); Mon, 11 May 2015 17:04:02 +0000 Original-Received: (at 20538) by debbugs.gnu.org; 11 May 2015 17:03:22 +0000 Original-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 Original-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 Original-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 In-Reply-To: <55507FA7.7020906@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:102673 Archived-At: 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