bug#33498: 26.1; Unable to delete minibuffer-only+child frames

[martin rudalics <rudalics@gmx.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