Re: Key bindings proposal

[Uday S Reddy]

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 
them otherwise.

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.

Cheers,
Uday