[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Key bindings proposal
From: |
Uday S Reddy |
Subject: |
Re: Key bindings proposal |
Date: |
Fri, 27 Aug 2010 09:18:52 +0100 |
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
- Re: Key bindings proposal, (continued)
- Re: Key bindings proposal, Stephen J. Turnbull, 2010/08/25
- Re: Key bindings proposal, Juri Linkov, 2010/08/26
- Re: Key bindings proposal, Miles Bader, 2010/08/26
- Re: Key bindings proposal, Juri Linkov, 2010/08/27
- RE: Key bindings proposal, Uday S Reddy, 2010/08/27
Re: Key bindings proposal, Andreas Schwab, 2010/08/23
Re: Key bindings proposal,
Uday S Reddy <=