From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andreas Politz Newsgroups: gmane.emacs.bugs Subject: bug#33498: 26.1; Unable to delete minibuffer-only+child frames Date: Sun, 25 Nov 2018 20:33:06 +0100 Message-ID: <87d0qtgdfx.fsf@hochschule-trier.de> References: <8736rpfklv.fsf@hochschule-trier.de> <5BFADE8C.9040500@gmx.at> <87h8g5ggft.fsf@hochschule-trier.de> <5BFAF08C.6080500@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1543174330 2935 195.159.176.226 (25 Nov 2018 19:32:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Nov 2018 19:32:10 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: 33498@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 25 20:32:06 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 1gR08R-0000ac-RO for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Nov 2018 20:32:03 +0100 Original-Received: from localhost ([::1]:60997 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gR0AY-0006Dy-6b for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Nov 2018 14:34:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42616) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gR0AS-0006Di-6Q for bug-gnu-emacs@gnu.org; Sun, 25 Nov 2018 14:34:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gR0AM-00009t-Nm for bug-gnu-emacs@gnu.org; Sun, 25 Nov 2018 14:34:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43354) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gR0AM-00008X-CH for bug-gnu-emacs@gnu.org; Sun, 25 Nov 2018 14:34:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gR0AM-0006BU-0n for bug-gnu-emacs@gnu.org; Sun, 25 Nov 2018 14:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Andreas Politz Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Nov 2018 19:34: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.154317439323713 (code B ref 33498); Sun, 25 Nov 2018 19:34:01 +0000 Original-Received: (at 33498) by debbugs.gnu.org; 25 Nov 2018 19:33:13 +0000 Original-Received: from localhost ([127.0.0.1]:47612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gR09Y-0006AP-Q5 for submit@debbugs.gnu.org; Sun, 25 Nov 2018 14:33:13 -0500 Original-Received: from gateway-a.fh-trier.de ([143.93.54.181]:59954) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gR09W-0006AG-Q9 for 33498@debbugs.gnu.org; Sun, 25 Nov 2018 14:33:11 -0500 X-Virus-Scanned: by Amavisd-new + Sophos + ClamAV [Rechenzentrum Hochschule Trier (RZ/HT)] Original-Received: from localhost (x4dbda2e4.dyn.telefonica.de [77.189.162.228]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-a.fh-trier.de (Postfix) with ESMTPSA id 65E5217D0995; Sun, 25 Nov 2018 20:33:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=hochschule-trier.de; s=default; t=1543174387; bh=JGT6rocE0VIxqccLpa+GybJpZ5Y=; h=From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=QGBzP+391vzvrpmXpyeD1cyhWUpiK4Er3MI2ztuwwD8fQCpMreGjzgwRZtxpwriB6 gKtlzqNisqKBPh2BEv222RwK4KimdFHdz7P/uVzQRO31KktI53uJWsWIYNpmzX5y0V arKgM/IIEh9ryyL0N9t7Os69k0Fez1pgIerzOv5o= In-Reply-To: <5BFAF08C.6080500@gmx.at> (martin rudalics's message of "Sun, 25 Nov 2018 19:57:16 +0100") 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:152768 Archived-At: martin rudalics writes: > [...] What I mean is the usual expanding/shrinking of the minibuffer > window you can observe on a normal minibuffer equipped frame. For > example, via (message"\n\n"). I see. > 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. >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. Andreas