Re: Key bindings proposal

[Uday S Reddy]

Juri Linkov writes:

> All in all, is it a conclusion we are leaning towards:
> 
> 1. All commands should have a name designed for M-x completions.
> 2. Most commands should be presented in the main menu.
> 3. Few basic commands should be bound to a key sequence.
> 4. Some of most frequently used command should be added to the toolbar.

Dear Juri, Thanks for an excellent summary and putting the life back
into this thread!

A couple of amendments.  My proposal for 

> 1. All commands should have a name designed for M-x completions.

wasn't actually that M-x should be extended or modified.  Rather, a
prefix key like M-x (say, M-z for argument's sake) would be used for
invoking mode-specific "command names".  Each mode would bind such
command names to actual elisp functions, and this allows us to reuse
the command names in each mode.

So `M-z isearch' can provide isearch through files in dired, isearch
through buffers in buf-menu, isearch through messages in Rmail or Gnus
or VM, etc.  Similarly, you might have commands `M-z next', `M-z
previous', `M-z view', `M-z other-window', `M-z mark', `M-z delete',
`M-z undelete', `M-z execute' and so on.

The key idea is that command names form a *new namespace*, created
explicitly for providing efficient user interaction.  

In addition, my idea also includes:

1a. key bindings can be made to "command names".

This allows the user to create a personal keymap like
  
  n for M-z next
  p for M-z previous
  v for M-z view
  o for M-z other-window
  m for M-z mark
  d for M-z delete
  u for M-z undelete
  x for M-z execute
  ...

and install it in every mode where it might make sense.  This would
save work for configuration and re-skinning.

Note that Stephen Turnbull countered by saying that a lot of this can
already be achieved using the existing elisp technology.  I am not
entirely convinced, but those suggestions need to be explored.

Regarding:

> 2. Most commands should be presented in the main menu.

I don't have a firm view on this.  There is also a case for having
simple menus that are not intimidating.  

But, I think one can probably have the cake and eat it too in this
case.  It is easy enough to install different menus depending on the
user's preference.  A beginner might start with simple menus, and
graduate to bigger ones when he/she wants more.

Regarding the contentious issue:

> 3. Few basic commands should be bound to a key sequence.

we will probably need to continue debating it.  "Less is more" only if
the users can turn it into "more".  If the users have a good
technology for making their own key bindings, then Emacs can ship with
fewer and fewer built-in key bindings.  Or, you can at least detach
the majority of key bindings from standard Emacs and make them
customization packages.

I will be going offline for a few weeks.  I will catch up after I get
back.

Cheers,
Uday