[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

quitting help buffer

From: Drew Adams
Subject: quitting help buffer
Date: Thu, 8 Sep 2005 20:56:55 -0700

I cannot figure out how to make `q' do what it used to do in Emacs 20, to
quit the *Help* buffer.

I use non-nil `pop-up-frames'. I want `q' to do the equivalent of
`quit-window'. In my context, that will kill the buffer and delete its frame
(thanks to my redefining `delete-window' to DTRT for one-window
pop-up-frames).  Bye; good riddance.

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)?

BTW, I find the doc string for view-mode difficult to understand wrt the
various quitting scenarios. It doesn't help that there are multiple
similarly named commands that use synonyms for "quit" as their only


What is this? The variations don't tell us anything in particular about what
the functions do - there is no significant difference between the words
"quit", "exit", and "leave".

Why not also
View-split, -give-up, -depart, -drop-out, -relinguish, -throw-in-the-towel, 
-take-leave, -go-away, -go-out, -get-out, -pull-up-stakes, and -escape? Or
are those variants being saved for Emacs 23? Not to mention combinations of
these with possible subsequent
actions: -and-kill, -and-pass-out, -and-hang-around, -and-go-down-to-the-poo

Could this be a sign that something is wrong in the design? Isn't it a bit
bizarre for a command to spend so much effort trying to deal with all of the
possible ways and contexts in which it might be called (used)? Shouldn't
such concerns be for the callers and not the callee? This seems bass
ackwards, to me.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]