RE: Key bindings proposal

[Drew Adams]

> 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
> `dired-isearch-filenames'.

Please don't. There are lots of 3rd-party extensions to Dired (etc.) whose
commands do not start with the prefix `dired-'. Typically, they start with the
3rd-party library prefix. Likewise, for personal user commands that are useful
in Dired (etc.).

There is no problem getting completion to filter only to a given prefix or
substring or whatever, even in vanilla Emacs (e.g. using completion styles).
Hard-coding prefix matching for the current mode is truly misguided.

> So if we had a separate top-level menu "_S_earch"

I've long argued for such a top-level menu. I've used a `Search' menubar menu
for decades. There is lots of stuff on other menus that really belongs on
`Search', and it's helpful for it to be top level. If people are worried about
menu space, then move something like `Options' back under `Help' or `File' (it
was originally under `Help').

This is a useful change independently of the reason you gave (use of menu
accelerators).

> 4. Toolbar (a flat menu with icons).

If changes are to be envisioned for the tool bar, they should be along lines
already suggested previously: allow for multiple actions, popup menu, etc. per
icon (e.g. via modifier keys).

The only things particular about a tool bar should be (1) icons, (2) immediate,
single action by clicking.

Emacs provides a deep, rich user experience with multiple levels of interaction.
Emacs tool bars could be made richer and more useful while retaining their
simplicity for novice use. There is no reason to limit Emacs tool bars to what
are available in some other apps. And even some other apps have tool-bar icons
that allow more complex interaction.

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

That is definitely not a conclusion (4 conclusions) that I am leaning toward.

#1: Naming a command can take completion into account to some degree, but that
should be only a minor consideration. There are other things important about
command names (discoverability, naming patterns for the library, relation to
other commands,...).

#2: A command should be put on a menu only when it is helpful to provide it with
menu access and organization (e.g. discoverability, association with similar
commands). It makes no sense to say that "most" commands should or should not be
on menus, let alone the "main menu" (whatever that might be).

#3 is particularly off the wall. (Though it's unclear what you might mean by
"basic commands".)  Having a command bound by default does not prevent anyone
from rebinding it to a different key. It is true that many commands need not be
bound by default, but it is also true that many are not bound by default. There
is no problem here that needs to be solved.

#4: Some should. Some should not. This is a vacuous conclusion.