RE: special buffer frames again

[Drew Adams]

> And actually, someone who uses such a setup recently complained on
> emacs-devel about a change I made that caused the frame to be
> deleted rather than iconified, so frame deletion doesn't seem good
> either.  IIRC this someone was called "Drew Adams", maybe you know him ;-)

Please; we disagreed in that thread, including disagreeing about what was
said in the previous thread (!). Please don't spread confusion to a third
thread (and another mailing list) that has been about something different.
*Backtrace* is not the same kind of "temporary" buffer as *Completions*:
it's not obvious when someone is finished with *Backtrace*.

I was clear from the beginning (my bug report after your changes) about my
own preferences for the *Backtrace* frame:

1. Emacs 20 and 21 were fine for this - just leave the frame alone, and let
users delete it when they're done with it.

2. Your change to have automatic iconification was annoying.

3. After discussion/negotiation, I was OK with deleting the frame
automatically, instead of iconifying it - but I still prefer the Emacs 20/21
behavior here.

IOW, you preferred auto-iconification of *Backtrace*; I preferred leaving
the frame for me to delete explicitly (`C-k' or `C-0'), and the compromise
was to delete the frame whenever the user hits `q'.

Different buffers have different uses and different criteria of "done".
*Help*, for instance, should be left as is until the user explicitly quits
(`q'), at which point its standalone frame should be deleted, not iconified.
Quitting *Backtrace* with `q' isn't equivalent, IMO. It doesn't signal that
the user is finished debugging; it means only that s?he wants to quit that
particular debugging invocation and return to top level. A standalone
*Completions* frame should be deleted (not iconified) whenever completion is
finished (e.g. `RET').

People have different practices; one is not wrong and the other right. It
would be good to 1) have reasonable default behavior that reflects what many
or most people want, but also 2) let users customize the behavior easily.
Perhaps we can agree on at least that much, and then look for ways to do
that?

An unconfigurable compromise, such as that for *Backtrace*, is bound to be
unsatisfactory all around, even if the best possible compromise is found.
Both you and I should be able to get the behavior we like for something like
*Backtrace*, without individually hacking the bowels of the source code.
Likewise, for *Help*, *Completions*, and so on.