[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Key bindings proposal
Uday S Reddy
Re: Key bindings proposal
Sat, 31 Jul 2010 11:04:50 +0100
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20100713 Thunderbird/3.1.1
On 7/31/2010 8:16 AM, Mathias Dahl wrote:
I just use C-s. In my Emacs the binding you mention does not exist, so it is
probably a quite new invention.
I think we are talking at cross purposes. This whole discussion has been about
how to organize the key bindings for local keymaps set up by Emacs modes in
such a way that users can modify them easily. Modifying the global bindings is
a piece of cake. So, they are not under discussion. (Well, not as far as they
don't impinge on local keymaps.)
M-s a C-s is indeed a recent key binding. The ChangeLog.14 file gives a date
of 2008-07-28, and grep shows that there are four modes that use it: buff-menu,
dired, ibuffer and vc-dir. I was giving this as an example of how Emacs
developers feel *compelled* to put functions on keys. The reasons could be (a)
they believe that all commands are supposed to be on keys, or (b) they think
the users won't use them otherwise, or (c) they think the users won't notice
The problem (a) is a policy issue. I don't know if there is a policy that all
commands are supposed to be on keys. But, if there is one, it can be changed
easily. So, this is not a big deal.
The problem (b) is a real one. Practically nobody is going to type M-x
dired-do-isearch to invoke this function. So, even these twisted key bindings
will probably get used by those that need them.
My idea was why can't one type something like "M-x isearch" to get this
function, instead of "M-x dired-do-isearch" which is too long-winded and "M-s a
C-s" which is too twisted and unmemorable? This requires a new concept for
Emacs, bindable command names that can vary across modes. (Stephen Turnbull is
going to say that you can already get its effect through some other means.
That is all well and good. The discussion right now is really about how to set
up an architecture that is functional for the users. Not everything whose
effect can be achieved by other means becomes part of the architecture unless
we use it appropriately!)
The problem (c) is a real one too. But the solution is self-defeating. Once
all the developers start scrambling for the limited keymap space in an effort
to attract the users' attention, the keymaps grow and grow and they stop
attracting anybody's attention. To get to C-s a M-s in the dired-mode's doc
string, I had to do some 12 page-downs! Doubtless my attention has wandered
off before then.
I stopped reading mode doc-strings somewhere around Emacs 19, when they started
getting longer than Unix man pages. (And, I stopped using Unix when its man
pages became unreadable too.) Fortunately, Emacs has info, which I use
regularly. But my impression is that the vast majority of Emacs users don't
use info. Xah Lee is right that the info manual has begun to read more and
more like a PhD thesis than a user manual, and unfit to look up information
quickly unless you already know its structure well. But let me not go into
that issue here.
Keyboard navigation of the menubar is a potential solution for both the
problems (b) and (c). But, as I mentioned earlier, this idea hasn't yet been
taken seriously in Emacs. The menu entries don't have key strokes associated
with them. At least on Windows, one can get to each menu item by typing the
first letter of the item. But this gets tedious if
- there are many menu items starting with the same letter (for example, look
under the "Mark" menu in dired) and
- when there is no way to sort the menu items alphabetically.
On second thought, perhaps the menus are not as disorganized as I had imagined.
I haven't yet begun to use them seriously. Since you seem to have first-hand
experience with their use, I should go by your word that they work well. I
would personally prefer if the menu items had key strokes associated with them
rather than the default first-letter-selection mechanism. This would also be
in line with all the well-designed GUI applications out there.
Coming back to the original issue, the over-reliance on key bindings gets in
the way of users trying to move the key bindings around. Even the remapping
idea, which is good in concept, is defeated if the mode developers have
hard-wired key bindings. And, a lot of the time the mode developers have used
up pretty much all the key space there is. So, the remapping idea becomes useless.
To give a concrete example, let us say that a user wants to use i-j-k-m
mnemonics for movement instead of p-b-f-n. He can bind C-m to next-line etc at
the top-level however hard it might be. But then every mode will probably have
some bindings that depend on the p-b-f-n mnemonics. The dired mode had C-n
bound to dired-next-line, which has now been changed to [remap next-line].
That helps the user. But dired mode also has `n' bound to dired-next-line. It
is not possible to move it to `m' by remapping. In some other modes (e.g., VM
summary mode), C-n is not used, but just `n' for the mode-specific movement.
Thus the user has to solve the same problem again and again. This is not the
whac-a-mole problem because it is the *same* mole that crops up in each mode,
not a different one.
So, the more keys the developers bind, the harder it is for the users to move
them around. Getting away from the key binding culture will help such users.
Re: Key bindings proposal, Uday S Reddy, 2010/07/29
coding guidelines? (was Re: Key bindings proposal), Joe Brenner, 2010/07/29
Re: Key bindings proposal [Was: Emacs learning curve], Noah Lavine, 2010/07/28