RE: quitting help buffer

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

        I don't want `q' to iconify the frame, slip it in my back
        pocket, mail it to
        me, or do any of the other strange and wonderful things I
        see advertised in
        the doc for `view-mode'. How can I get `q' to do something
        as simple as kill
        the buffer and delete its window (frame)?

    When I try it, it deletes the frame but does not kill the buffer.
    Isn't that good enough?  Is it crucial for some reason to kill
    the *Help* buffer?

No, there is no need to kill the buffer - deleting the frame is what I'm
really after, here. Sorry if I confused the two (I often end up killing the
buffer to delete the frame, because my `C-x k' does that).

But that is not the behavior I get. For me, it iconifies the frame. And, in
some (rarer) cases, it leaves the frame displayed (no change): `q' does
nothing at all in those cases.

I suppose it depends on how (in what context) the *Help* buffer was
displayed. (It could also have something to do with my platform?) I don't
have the time now, myself, to track down the different contexts.

This is part of what I meant by our trying to be too sophisticated wrt
figuring out how view-mode was entered and how to most intelligently exit
it. It's too complicated for me to follow, and, in particular, it doesn't
DTRT when pop-up-frames = t.

The latter is a general problem, which I've mentioned before: things are
worked out well enough for the case where pop-up-frames = nil, but not for
`t'. In this case, due to the myriad fancy treatments of view-mode quitting,
it's hard to fathom what to do to make it work right for pop-up-frames = t.
And then there are dedicated and non-dedicated windows to worry about...

Bottom line: I'd like `q' to delete a one-window frame (dedicated window or
not). How to do that in all of the various view-mode cases, I know not.

(More generally, I don't see why a command should worry so much about how it
was called, and try to figure out what to do next, based on the calling
context - that seems the wrong approach, to me.)