emacs-devel
[Top][All Lists]
Advanced

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

Re: Key bindings proposal


From: Thierry Volpiatto
Subject: Re: Key bindings proposal
Date: Mon, 23 Aug 2010 16:14:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Hi Juri,

Juri Linkov <address@hidden> writes:

>> 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-

If you use anything, you have to try anything-M-x (<f5-a> M-x) that give
you history (easy to use, no need to know M-p/n) and describe commands
under point with C-z (without quitting M-x).
  
> Similarly e.g. in Dired, M-x could guess the `dired-' prefix
> for Dired commands, so you could just add `isearch' to run
> `dired-isearch-filenames'.

If you know that something is called isearch in emacs. ;-)

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

That what does anything-M-x.

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

-- 
Thierry Volpiatto
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 




reply via email to

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