[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: quitting help buffer
From: |
Drew Adams |
Subject: |
RE: quitting help buffer |
Date: |
Fri, 9 Sep 2005 09:05:35 -0700 |
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.)