From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#33498: 26.1; Unable to delete minibuffer-only+child frames Date: Mon, 26 Nov 2018 10:31:06 +0100 Message-ID: <5BFBBD5A.4060002@gmx.at> References: <8736rpfklv.fsf@hochschule-trier.de> <5BFADE8C.9040500@gmx.at> <87h8g5ggft.fsf@hochschule-trier.de> <5BFAF08C.6080500@gmx.at> <87d0qtgdfx.fsf@hochschule-trier.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1543224610 28265 195.159.176.226 (26 Nov 2018 09:30:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Nov 2018 09:30:10 +0000 (UTC) Cc: 33498@debbugs.gnu.org To: Andreas Politz Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 26 10:30:05 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gRDDQ-0007Ab-NN for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Nov 2018 10:30:04 +0100 Original-Received: from localhost ([::1]:34806 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRDFX-0001Oq-2D for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Nov 2018 04:32:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRDFO-0001Oe-Ro for bug-gnu-emacs@gnu.org; Mon, 26 Nov 2018 04:32:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRDFK-0001wr-9J for bug-gnu-emacs@gnu.org; Mon, 26 Nov 2018 04:32:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43543) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gRDFK-0001wa-67 for bug-gnu-emacs@gnu.org; Mon, 26 Nov 2018 04:32:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gRDFJ-0001TG-Ur for bug-gnu-emacs@gnu.org; Mon, 26 Nov 2018 04:32:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 26 Nov 2018 09:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33498 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33498-submit@debbugs.gnu.org id=B33498.15432246795598 (code B ref 33498); Mon, 26 Nov 2018 09:32:01 +0000 Original-Received: (at 33498) by debbugs.gnu.org; 26 Nov 2018 09:31:19 +0000 Original-Received: from localhost ([127.0.0.1]:47801 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gRDEd-0001SE-79 for submit@debbugs.gnu.org; Mon, 26 Nov 2018 04:31:19 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:60461) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gRDEa-0001Rx-Rj for 33498@debbugs.gnu.org; Mon, 26 Nov 2018 04:31:17 -0500 Original-Received: from [192.168.1.101] ([46.125.249.31]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LjJCt-1fpwP30C1X-00dTop; Mon, 26 Nov 2018 10:31:10 +0100 In-Reply-To: <87d0qtgdfx.fsf@hochschule-trier.de> X-Provags-ID: V03:K1:Ip5xU73FUH2LUXg1LLv6TcIiaLgSlFJnFL21/xi+wGJj89oWaHg TKD+orgj3hc4DE9w6x283wffR2bW44d45wP4p2ca+3Y+rvdDWlEG3OqN1XJbXErR7GjzQuh FVR+3VyaQvA8J2IotfqsRbNf6fVAsvWBl75r3B74lhzPT6589L1a/+gD9vS2g/2PIbfQcR3 aquoE2EjXmoPqYwQU8+yw== X-UI-Out-Filterresults: notjunk:1;V03:K0:tONVqpFMdBA=:gr5A9RWwdhNKeuc8ujOeJz Z75A7G2r5MaTUpmOXnnXi9iNT3A6JqRGnd6I0vbzaNjJOXYoHA3VIt35uKiqGgSY5/VY4M9HH RSQZk8dLl5P6M2BdIDI5DS7SBrvNXMMWaDsgGus4eGINERO8294lqbuPmw6Kf0M+fqg/6uBzL i6OdPjIssXhKDB5cs1w0D5kSK+VKlNM1sgUNTfwJmp8IrsXcfqSxI5SYOv8O9T76Q/MrD7VZ1 WaFgYBtWrrey/2S3bvL+6bZbGsxEm9pl/Y+GEu7HBx1N/1gGnGOuQY2fvPdfnasS6BbsH/72X h+kJfUD23ehFXpk3bc/TvYVOWeSoWb0QNeXZDQ61+ZeSjxoqao3Lgq6BKiLh55xHjwUBRAiT+ 4lxd8Nc14KP8hdgeCMn9YOXL67rlS7X/xyyf8ZTBUAqKNd39ArfGNLBhs0YF0Y9LnwV/dOoj6 ChUT4Dh6Fo2+kWbnBsijtYuwzTU/MDCynQMWo3lJK6r+Zh70rUz2sebbaXEBzO90js7mB1U8p 8aJmQhS828bNlbYcEx9b/lPvhwNFItHbW9VcG5LUlDO0IopTj0GTsYuWiCZrT5T4qvLrkHbvP /drulMAA0CnbQNJTnIvCpmv57PcO0MND8bFtf5FTwYlz3jJX6DWC3wX0UyTHSEA7NSD4szELe SVSyerviHtz4hBd+RSjMiH10LYWmLGmh695bgZiEAM2tZrotmg6Wg31jIBe9UVRA6X46VMut1 mjanLT++vpKwrhgWmRGRrE5bP0WcY3Gr9EODlUMwCCY3QnYhwYct0+iMa54oDyolMliFAM86 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:152778 Archived-At: >> For internal reasons each live frame must have a minibuffer window. >> This is hardcoded in a couple of internal routines and if you remove >> that restriction (it's the "Attempt to delete a surrogate minibuffer >> frame" in frame.c) [...] > > I don't mean to remove that restriction. But in this case, where the > parent is deleted and the child is the parent's minibuffer-frame (and > there are no other frame using this minibuffer-frame) this restriction > doesn't seem to apply, at least on a conceptual level. Agreed. But the only way to delete the parent frame is to do what you did - untie the minibuffer frame first by making it top-level and then delete its former parent. The problems with this are the same you probably see when you create the minibuffer frame: the minibuffer frame becomes first visible on the desktop as a top-level frame before it gets moved and subordinated to the parent frame. When deleting the parent frame you see the inverse effect: the minibuffer frame becomes top-level on the desktop and stays there in some orphaned fashion until you eventually kill it. These operations would have to be automatized and improved as follows: Process a (minibuffer . child-frame) frame parameter to (1) make an _invisible_ top-level minibuffer-only frame similar to what we are doing in the (minibuffer . nil) case, (2) create the minibuffer-less parent frame with the minibuffer window set to the window made in (1), (3) reparent the minibuffer frame created in (1) and make it visible. Then deleting the parent frame would (4) make the minibuffer frame invisible and top-level, (5) delete the parent frame, (6) delete the minibuffer frame if possible or make it visible if it still serves as minibuffer frame for another frame. (4)-(5) would have to handle the cases correctly where delete_frame (the C function) is called from Elisp (via C-x 5 0, for example) and from the window manager (by clicking the "x" on the title bar). The Elisp call would not shut down Emacs, the window manager call could. To process (6) we would maybe also want an 'auto-delete-minibuffer' frame parameter (which could then be also used for non-child-frame minibuffer-only frames). Finally, any such code will have to process the 'delete-before' frame parameter appropriately to avoid running into an infinite loop of failed deletion attempts. >>From the point of a user, this means that he either needs to advise > `delete-frame' or use a different command in order to delete these kinds > of frames. Indeed. Patches welcome. martin