bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions

["Drew Adams" <drew.adams@oracle.com>]

> This shared code can provide a hook to let the user choose 
> how the frame gets hidden, 

Why make users jump through hoops and hooks?  Provide a user option.  (And
removing is not "hiding".  And even hiding does not leave behind little icons.)

> but the default should be to iconify since that's how it's
> worked until now

Oh, that's rich.  If you resist bug reports long enough, sure, you can then
claim that "that's how it's worked until now", and that's the reason it should
continue to be the default ("since").

But no, that's not how it worked, even as recently as Emacs 22, IIRC.  At least
in Emacs 18,...21,22 quitting the debugger, say, does _not_ iconify a dedicated
*Backtrace* frame - it simply _deletes_ it - behavior that makes sense.

Seems to me this iconification is something that you introduced.
Iconifying is hardly "how it worked" before that.

emacs -Q ; Emacs 22
(setq special-display-regexps '("[ ]?[*][^*]+[*]"))
M-: (/ 0)
q ; in buffer *Backtrace*.  Poof - the frame is _deleted_.

So by your logic, "since" that's _not_ how it worked throughout Emacs's history
until you introduced the iconification bug/feature, the traditional default
behavior should be restored: delete the frame.

> (and also because I think it's a safer default, in the
> sense that iconifying throws away less information than deleting the
> frame).

You did add "in the sense that", but it's not about _safety_.  Deleting a frame
does not destroy any important information (buffer/file content etc.).

And nothing prevents you from saving the frame position, shape, and size for
your own use - e.g. in a register.  Do that in a hook if you like.

But the default behavior should simply do what a user expects: _remove_ the
frame.  That could be done by making it invisible or deleting it.

Making it invisible would save all of your precious frame info, BTW.
Invisibility, like deletion (and unlike iconification), is instantaneous and
unclutters the display, and it would presumably be a reasonable compromise.  In
principle, it should address both your concerns and mine.

Supposedly, there are some bugs associated with invisible frames, but it's not
clear just what they are (?).  Maybe it's time to find out (and fix them).

In sum, invisibility would probably be an acceptable compromise default.
Iconifying as default should be a non-starter - a bad idea.

> the choice doesn't depend on the caller, AFAIK, but on the user.

Which means it should be easily customizable by the user - a user option, not
just hooks.