[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should Text motion commands have no menu entry?
From: |
Yuri Khan |
Subject: |
Re: Should Text motion commands have no menu entry? |
Date: |
Sun, 17 May 2015 21:39:18 +0600 |
On Mon, May 18, 2015 at 2:18 AM, Vaidheeswaran C
<address@hidden> wrote:
> I was looking at the http://www.gnu.org/software/emacs/tour/ hoping to
> get some inspiration for my "Emacs Primer". Man of the text
> navigation commands do NOT have a menu entry. Is it a deliberate
> decision? If not, can the situation be changed.
Menus have two functions:
* The executive function allows users to invoke a command if or when
they forget its keybinding or command name.
* The discovery function alerts users that a certain command exists,
and tells them its keybinding.
Menus also have a cost:
* As the number of menu items grows, the menu as a whole becomes
harder to grasp.
For cursor motion commands, especially such fine-grained ones as
“forward-char”, the executive function of the menu is very
inefficient. No one in their right mind will perform cursor motion by
repeatedly choosing e.g. Edit | Go to | Next character.
The discovery function is also diminished. Everybody knows that a text
editor *does* have cursor motion commands, and expects them to have
certain keybindings. (These happen to be arrows and editing-block
keys, not the supposedly super-efficient C-f C-b C-n C-p C-a C-e C-v
M-v. This does not actually matter.)
Additionally, the discovery function of the menu is duplicated by the
context help, which is called by F1 m in Emacs, and in other
applications usually by F1 followed by navigating the help index.
In the name of reducing the cognitive cost of the menu as a whole,
ubiquitous commands — such as cursor movement and instances of
self-insert-command for each of the 1114112 Unicode codepoints —
should not have corresponding menu items.