Should killing a help or compile buffer also delete the window?

[Daniel Brockman]

I've always found it annoying that Emacs seems to have a habit of
leaving junk windows around whenever you invoke something that needs
to display information in a temporary buffer.  I think it just gives a
really sloppy impression, especially when you aren't used to it.
Two of the most common examples might be `M-x compile' and `C-h f'.
It also happens with things like `M-x grep' and `M-x locate'.

I realize that you can't expect Emacs to know when you are done with a
window unless you actually tell when.  The obvious way to tell when is
to type `C-x 1' or `C-x 0', but this leaves the temporary buffer
lingering, which makes me nervous.

When I was new to Emacs, I would always kill a garbage buffer before
deleting its temporary window.  Eventually, I discovered `C-x 4 0' and
started using that.  As time went by (and I got lazier), I gradually
began to accept the fact that you really can't avoid having a bunch of
old garbage buffers unless you spend a lot of time chasing them down,
so I started just doing `C-x 1', though it always made me feel dirty.

Now to the point of this message.  Some time ago I started using
Dictionary Mode[1], which has caused me to once again pick up the
habit of killing temporary buffers.  As you might know, killing a
dictionary buffer automatically kills the window as well, unless the
window was already there when the dictionary buffer was created.
This makes a lot of sense to me --- so much sense that the normal
Emacs behavior has once again started to annoy me.

I believe the Right Thing to do when the user kills a temporary buffer
whose window was created as a side-effect of displaying the buffer in
question is to restore the old window configuration.  At least when
the automatically created window hasn't been used for anything else,
Emacs should take the hint and get the window out of the user's face.

I'm sorry if this is an old argument, or if this is not the right time
to discuss this matter.

-- 
Daniel Brockman <address@hidden>

[1] http://www.myrkr.in-berlin.de/dictionary/