GNU bug report logs - #33498
26.1; Unable to delete minibuffer-only+child frames

Previous Next

Package: emacs;

Reported by: Andreas Politz <politza <at> hochschule-trier.de>

Date: Sun, 25 Nov 2018 11:45:01 UTC

Severity: normal

Tags: fixed

Found in version 26.1

Fixed in version 27.1

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Andreas Politz <politza <at> hochschule-trier.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 33498 <at> debbugs.gnu.org
Subject: bug#33498: 26.1; Unable to delete minibuffer-only+child frames
Date: Sun, 25 Nov 2018 20:33:06 +0100
martin rudalics <rudalics <at> gmx.at> 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




This bug report was last modified 6 years and 89 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.