[Top][All Lists]

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

Re: Key bindings proposal

From: Juri Linkov
Subject: Re: Key bindings proposal
Date: Mon, 23 Aug 2010 14:45:27 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (x86_64-pc-linux-gnu)

> function has to be on a key or people won't use it.
> And the key combinations keep getting weirder and weirder.
> Like M-s a C-s to do an isearch!

Well, we have 4 basic input trees for input sequences
and usually are trying to add a command to all of them:

1. Command names for M-x.  An input sequence comprises of characters
of the command name, and completion helps making the input sequence shorter.
This have to be taken into account when designing a scheme for command
names (using an unique command name prefix, etc.)

To improve this type of input, we could try adding dwim completions
for M-x.  For instance, like the `calc-execute-extended-command' command
basically does the same as `execute-extended-command' but prefills the
minibuffer's input with the `calc-' prefix:

  M-x calc-

Similarly e.g. in Dired, M-x could guess the `dired-' prefix
for Dired commands, so you could just add `isearch' to run

For more convenience, this could also behave like completions
in text fields in web browsers and push the most likely completions
combined with more frequent items from the input history
to the top of the completions list.

2. Menus.  In a menu-driven program with menu accelerators
using Alt+Letter in a sequence like `M-s a C-s' selects
an action from the main menu.

So if we had a separate top-level menu "_S_earch" then using the menu
accelerator key `M-s' would open the Search menu.  Then the next key `a'
will select a submenu with the menu accelerator `a', and the final key
`C-s' will run a command bound to the menu item.  If the last key is RET,
it will select the first menu item.

3. Key sequences of input events.

You seem to suggest that we have to refrain from binding each and every
command to a key sequence since it duplicates two other input types above.

I tend to agree provided that M-x completions are as short as possible
and the menu structure is well-thought-out (balanced breadth and depth,
e.g. to reduce the length of the overlong File menu, print-related items
could be moved into a submenu with the "_P_rint" menu accelerator, etc.)

4. Toolbar (a flat menu with icons).

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.

reply via email to

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