Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

bug#631: the M- notation suggestion

2 views
Skip to first unread message

xah lee

unread,
Jul 30, 2008, 4:49:01 AM7/30/08
to bug-gn...@gnu.org

This is a suggestion on emacs's usability.

Recently in discussion at gnu.emacs.help, the subject of Alt+‹key›
vs M-‹key› came up.

I think emacs's M-‹key› notation is one of emacs's a usability
problem, contributing to its often cited big leaning curve.

Here's some detailed argument on why i think this should be chaged.
Many emacs old users probably don't agree, but i thought it's good to
send in one opinion anyhow.

---------------------

Emacs's M-‹key› Notation vs Alt+‹key› Notation

Xah Lee, 2008-07

Here're some reason i think emacs should adopt the Alt+‹key› and
Ctrl+‹key› notation throughout its documentation. (as opposed to
emacs's M-‹key› and C-‹key› notation)

UNIVERSALLY UNDERSTOOD

The Alt+‹key› or Ctrl+‹key› notation is universal among
Windows and Linux. They account for about 95% of computers used word
wide. Note that the word “Alt” and “Ctrl” are the exact labels
printed on the Keys of PC Keyboards. PC Keyboards has probably more
than 99% of market share.

IDENTICAL TO KEY'S LABEL

Using a notation that contains the actual label on keyboard's keys is
much easier to understand. A beginning computer user, can read the
“Ctrl+‹key›” notation and figure out which keys to press.
Emacs's notation of “M-‹key›” and “C-‹key›” requires a
learning step, even for experienced programers. Even though it is a
minor one, but learning steps add up the complexity.

(Apple's computers, which account for about %4 marke share today,
also use a notation where the name or symbol appears on the labels of
Apple keyboard's keys exactly. (OSX's documentation uses the notaton
“Command-‹key›” and “Option-‹key›”. Application's
menus shows them as “⌘‹key›” and “⌥‹key›”. Both
the word “Command” and symbol “⌘” appear on the key's label,
same for “Option” and “⌥”.)
Meta Is Alt In Practice

By default on all major OSes in use (Windows and Linux and OSX),
emacs maps its Meta to Alt key. So, practically speaking, the Meta
key is the Alt key. (Aquamacs, perhaps the most widely used emacs
distro on OSX, by default has Alt for Meta.)

KEYBOARDS DON'T HAVE META KEY TODAY

The Meta key was one of the modifier key on obsolete keyboards used
by lisp machines in the 1980s. (for photos and detail, see: Why
Emacs's Keyboard Shortcuts Are Painful)

There is practically no keyboard today that has the Meta key. Sun
Microsystem's keyboard has a key labeled with a diamond “◆”.
Sun's official documentation refers to this key as Meta key. (e.g.
search http://docs.sun.com/ on “Meta key”.) Sun's keyboards have a
market share perhaps less than 0.01%.

For photos and more commentary on Sun's keyboard, see Computer
keyboards Gallery.

MISC FACTS

Historically, a “Meta+‹key›” shortcut in emacs can also be
invoked by “Esc ‹key›” or “Ctrl+[ ‹key›”. The design
was that way mostly because at the time, many terminals do not have
or support the Meta key, and Terminal is a primary application in
computer use in the 1980s. The other reason is that, in emacs's
implementation, the Meta+‹key› is simply a ASCII control character
sequence. Today, perhaps all terminal↗, console↗, Command line
interface↗ apps support Meta as Alt either by default or in a
preference setting.

The ability of pressing Esc for Meta might be still useful for some
people. Users who needed that feature could easily read about it in
emacs doc. (I myself used “Esc ‹key›” exclusively during
1998-2004, mostly because it was a one-brainless solution that works
on all telnet apps regardless of hardware, OS, or setup, and i
frequently need to use different machine, OS, or remote servers.)

A argument from user interface perspective, is that multiple
insignificant choices or options are not good because it increases
complexity and causes the user to sidetrack their focus on tasks. KDE
and Gnome, solved this problem for linuxes by adopting wholesale
Microsoft Window's interface starting about 1998. (before KDE and
Gnome, GUI apps on unix use a variety of “Windows Managers” that
has incompatible User Interfaces, each claiming superiority.)

Note: Whether to use the “M-‹key›” or “Alt+‹key›”
notation has little to do with “Esc ‹key›” feature.

PS Note that Microsoft Windows used to use the Alt-‹key› notation.
Only in recent years they changed the minus sign to plus sign.
Arguably, this is a good change because the plus sign better
indicates key combination.

Xah
http://xahlee.org/


Richard M Stallman

unread,
Jul 30, 2008, 9:59:39 PM7/30/08
to xah lee, bug-gn...@gnu.org
The Alt+?key? or Ctrl+?key? notation is universal among
Windows and Linux.

I think you mean "GNU/Linux". Linux has no user interface and its
documentation has no reason to refer to any specific keys.

Our convention for the GNU system is C-x and M-x, which is what you
are proposing to change.

Using a notation that contains the actual label on keyboard's keys is
much easier to understand. A beginning computer user, can read the

?Ctrl+?key?? notation and figure out which keys to press.

There is some validity in that argument.

For the Emacs Manual I have a feeling this would be very wasteful.
But maybe it would be ok for some of the help commands, maybe even for
all of them.

xah lee

unread,
Jul 30, 2008, 10:53:21 PM7/30/08
to r...@gnu.org, bug-gn...@gnu.org
> I think you mean "GNU/Linux".


Yes. GNU/Linux. Sorry i forgot i'm talking to you. LOL. (i do support
GNU/Linux naming)

> Linux has no user interface and its
> documentation has no reason to refer to any specific keys.


In Gnome or KDE, when you pull menus, doesn't the shortcut shows
beside the menu command names?

I think I forgot to mention this. I think if this suggestion is to be
adapted, changing the shortcut notation as they are displayed in
menus should be part of it. Perhaps even more important than the manual.


> Our convention for the GNU system is C-x and M-x, which is what you
> are proposing to change.
>
> Using a notation that contains the actual label on keyboard's
> keys is
> much easier to understand. A beginning computer user, can read the
> ?Ctrl+?key?? notation and figure out which keys to press.
>
> There is some validity in that argument.
>
> For the Emacs Manual I have a feeling this would be very wasteful.
> But maybe it would be ok for some of the help commands, maybe even for
> all of them.


Wasteful, as in too much effort and little benefit?

I think the effort would be few hours of interactive find/replace in
the emacs manual's info source. O, there's also emacs tutorial info
file. Possibly a few more.

the other part is to fix the elisp code so that menus display
shortcuts using the Alt+ ant Ctrl+ notations. I'm not sure how this
can be done or how much effort it takes.

I think the benefit would be great, because it gets rid of one big
learning curve perception that stops people from using emacs.

Xah
http://xahlee.org/

-------------------

Lennart Borgman (gmail)

unread,
Jul 31, 2008, 1:30:36 PM7/31/08
to r...@gnu.org, 6...@emacsbugs.donarmstrong.com, xah lee, bug-gn...@gnu.org
Richard M Stallman wrote:
> Using a notation that contains the actual label on keyboard's keys is
> much easier to understand. A beginning computer user, can read the
> ?Ctrl+?key?? notation and figure out which keys to press.
>
> There is some validity in that argument.
>
> For the Emacs Manual I have a feeling this would be very wasteful.
> But maybe it would be ok for some of the help commands, maybe even for
> all of them.

Please put this on the TODO list. I think both the menus and the help
command should reflect the actual keyboard labeling (for a standard
keyboard on the used OS).


Lennart Borgman (gmail)

unread,
Jul 31, 2008, 1:30:36 PM7/31/08
to r...@gnu.org, 6...@emacsbugs.donarmstrong.com, xah lee, bug-gn...@gnu.org

Richard M Stallman

unread,
Jul 31, 2008, 6:01:23 PM7/31/08
to xah lee, bug-gn...@gnu.org
> Linux has no user interface and its
> documentation has no reason to refer to any specific keys.


In Gnome or KDE, when you pull menus, doesn't the shortcut shows
beside the menu command names?

Yes, but neither GNOME nor KDE is part of Linux.
Linux is just the kernel.

Richard M Stallman

unread,
Jul 31, 2008, 6:01:24 PM7/31/08
to xah lee, bug-gn...@gnu.org
> For the Emacs Manual I have a feeling this would be very wasteful.
> But maybe it would be ok for some of the help commands, maybe even for
> all of them.

Wasteful, as in too much effort and little benefit?

I mean reducing what's visible on a page, and wasting paper.
But someone could try it and see.

xah lee

unread,
Jul 31, 2008, 10:10:13 PM7/31/08
to r...@gnu.org, bug-gn...@gnu.org
Richard M Stallman wrote:
«Linux has no user interface and its documentation has no reason to
refer to any specific keys. »

Xah Lee wrote:
«In Gnome or KDE, when you pull menus, doesn't the shortcut shows
beside the menu command names?»

On Jul 31, 2008, at 3:01 PM, Richard M Stallman wrote:
«Yes, but neither GNOME nor KDE is part of Linux. Linux is just the
kernel.»


I was rather confused by the purpose or relevance of this remark for
a total of estimated 60 seconds. (not a joke)

Xah
http://xahlee.org/


xah lee

unread,
Jul 31, 2008, 10:07:37 PM7/31/08
to r...@gnu.org, bug-gn...@gnu.org
On Jul 31, 2008, at 3:01 PM, Richard M Stallman wrote:

For the Emacs Manual I have a feeling this would be very wasteful.
But maybe it would be ok for some of the help commands, maybe even for
all of them.


Xah wrote:
Wasteful, as in too much effort and little benefit?

RMS wrote:
I mean reducing what's visible on a page, and wasting paper.
But someone could try it and see.


who's doing this?

and what about making the menu show the Alt+ and Ctrl+ notation? Is
anyone in particular doing it?

PS give me a hint perhaps on how to do the latter. I might experiment
on both.

Xah
http://xahlee.org/


Yavor Doganov

unread,
Aug 1, 2008, 2:39:09 AM8/1/08
to Lennart Borgman (gmail), 6...@emacsbugs.donarmstrong.com, r...@gnu.org, xah lee, bug-gn...@gnu.org
Lennart Borgman (gmail) wrote:
>
> I think both the menus and the help command should reflect the
> actual keyboard labeling (for a standard keyboard on the used OS).

IMHO this is close to impossible, since GNU/Linux runs on a variety
(at least 10) architectures, including archaic and modern machines
that have vastly different keyboards. So there are many "standard
keyboards" for the OS GNU/Linux, also for the various free variants of
BSD.

"M-" existed since about forever; wiping it out will do more harm than
good. If a new Emacs user has problems understanding it and finding
the right key on her keyboard, she surely will have much more problems
with other Emacs features, let alone more complicated concepts and
advanced usage.

Also, you should not consider only the Emacs manual. Think of the
tens or hundreds of manuals of add-on packages, non-Emacs packages
(like Texinfo), and knowledge base like the mailing lists or sites
like the Emacs Wiki. Changing something as fundamental as this for no
apparent benefit is a bad idea. IMHO.


xah lee

unread,
Aug 1, 2008, 2:53:06 AM8/1/08
to r...@gnu.org, bug-gn...@gnu.org
PS if someone send me url for the texinfo source for the emacs manual
and emacs tutorial, i'll be happy to send back the modifier version,
where any M- or C- notation is changed to Alt+ and Ctrl+, and any
relevant place that might needs to be edited.

btw, the texinfo source for the emacs manual on the official gnu site
may be outdated or bad. Two years ago i tried to use it and ends up
spending several hours fruitless, finally got helped by given the url
for a good copy of the texinfo source. (For detail see http://
xahlee.org/emacs/gnu_doc.html )

Xah
http://xahlee.org/


Yavor Doganov

unread,
Aug 1, 2008, 2:39:09 AM8/1/08
to Lennart Borgman (gmail), 6...@emacsbugs.donarmstrong.com, r...@gnu.org, xah lee, bug-gn...@gnu.org

xah lee

unread,
Aug 1, 2008, 3:42:19 AM8/1/08
to Yavor Doganov, bug-gn...@gnu.org, 6...@emacsbugs.donarmstrong.com, r...@gnu.org
Lennart Borgman (gmail) wrote:
«I think both the menus and the help command should reflect the
actual keyboard labeling (for a standard keyboard on the used OS).»

On Jul 31, 2008, at 11:39 PM, Yavor Doganov wrote:

«


IMHO this is close to impossible, since GNU/Linux runs on a variety
(at least 10) architectures, including archaic and modern machines
that have vastly different keyboards. So there are many "standard
keyboards" for the OS GNU/Linux, also for the various free variants
of BSD.

»

Microsoft Windows and GNU/Linux systems, together has about 95%
market share of all computing systems. Their keyboard is typically PC
keyboard, which has i estimate 99.9% market share world wide. Apple's
computers use their own Keyboard but also has Alt and Ctrl printed on
the keys.

So, practically speaking, this wouldn't effect those ~0.1% machines
that emacs supports. For these users, typically they are advanced
programers and they know what they are doing. (for example, if they
want to browse the web, use a particular programing language, game,
or software, they will typically find those not supported or under
supported on their platform, but it is well expected.)

Yavor wrote:
«


"M-" existed since about forever; wiping it out will do more harm
than good. If a new Emacs user has problems understanding it and
finding the right key on her keyboard, she surely will have much more
problems with other Emacs features, let alone more complicated
concepts and advanced usage.

Also, you should not consider only the Emacs manual. Think of the
tens or hundreds of manuals of add-on packages, non-Emacs packages
(like Texinfo), and knowledge base like the mailing lists or sites
like the Emacs Wiki. Changing something as fundamental as this for
no apparent benefit is a bad idea. IMHO.

»

I think you are right that to do this completely would be near
impossible, because that's over-riding some 25 or so years of emacs
history. However, i think the benefit still outweight the negatives.

Also, changes that are few order of magnitude happens in commericial
world often. A good example is Apple computer's switch from Motorola
chip to PPC chip ~1995, and Mac OS to OSX ~2001, and PPC chip to
Intel chip ~2006.

Some of these changes maintained some level of compatibility, but in
general it wiped out several years of accumulated code,
documentations, and world wide user expectations on how these
software worked. Same happens in Microsoft's products. These
commercial corps do that in order to survive.

Emacs does not have a survival problem, at least not in the sense of
commercial software. Emacs also have small number developers, most on
a voluntary basis. I htink the effort required in this change is
relatively small, the benefit is arguably good because it reduces the
number one complaint people have about emacs, namely being difficult
to use or learn.

The issue, about the impact of this manual change, on past emacs
related documents, esoteric systems, and old emac user's
expectations, is neglectable i think, because software systems
changes all the time with accumulated baggage. For a OpenSource
example, Perl went from perl4 to a incompatible perl5 starting in
1993, and it went on to thrive in the dot com era (~1998).

The proposed change doesn't actually effect elisp code. It is
primarly esthetic in nature.

There's a large thread discussing this issue, at:

Newsgroups: gnu.emacs.help
Date: Thu, 24 Jul 2008 10:36:02 -0700 (PDT)
Subject: What does 'run' do in cperl-mode?

http://groups.google.com/group/gnu.emacs.help/browse_frm/thread/
5b81fcfd40d1f4ca/

After the first 5 or so messages, the rest 60 or so is about
discussing M- vs Alt+ issue.

The debate is somewhat heated, but i think it hasn't degerated into
bad usenet flame feast. Most disagree with the change. If would be
great if those of you interested in the issue have a peek there.

Xah
http://xahlee.org/


xah lee

unread,
Aug 1, 2008, 3:42:19 AM8/1/08
to Yavor Doganov, bug-gn...@gnu.org, 6...@emacsbugs.donarmstrong.com, r...@gnu.org

Lennart Borgman (gmail)

unread,
Aug 1, 2008, 4:37:17 AM8/1/08
to Lennart Borgman (gmail), 6...@emacsbugs.donarmstrong.com, r...@gnu.org, xah lee, bug-gn...@gnu.org, ya...@gnu.org
Yavor Doganov wrote:
> Lennart Borgman (gmail) wrote:
>> I think both the menus and the help command should reflect the
>> actual keyboard labeling (for a standard keyboard on the used OS).
>
> IMHO this is close to impossible, since GNU/Linux runs on a variety
> (at least 10) architectures, including archaic and modern machines
> that have vastly different keyboards. So there are many "standard
> keyboards" for the OS GNU/Linux, also for the various free variants of
> BSD.

I am not suggesting that this should work for every keyboard, but it
could work for the most common. In the other cases we could just stick
to the current notation in help and menus.

> "M-" existed since about forever; wiping it out will do more harm than
> good. If a new Emacs user has problems understanding it and finding
> the right key on her keyboard, she surely will have much more problems
> with other Emacs features, let alone more complicated concepts and
> advanced usage.

Why? I remember myself searching for the <copy> key for example.

> Also, you should not consider only the Emacs manual. Think of the
> tens or hundreds of manuals of add-on packages, non-Emacs packages
> (like Texinfo), and knowledge base like the mailing lists or sites
> like the Emacs Wiki. Changing something as fundamental as this for no
> apparent benefit is a bad idea. IMHO.

I do not think it is realistic or useful to change the manuals. It is
static. I also do not think the notation for adding key binding can be
changed. However the dynamic bits in menus and help can perhaps be
changed without a very big effort. That change can be useful for newcomers.

I think this could be handled by just changing some central code in
Emacs, but I am not sure. Here is a list of what I think must be handled:

Implement M- => Alt-

- Change push_key_description
- Increase #define KEY_DESCRIPTION_SIZE ((2 * 6) + 1 +
(CHARACTERBITS / 3) + 1 + 1)
- Add option for whether to do M- => Alt-
- Add keyboard values
- Add OS dependent default values for "Alt"
- Change the macro that reads those key sequences and converts them
to vector format

I might be missing a lot of things so please add to this list if you are
interested.

Lennart Borgman (gmail)

unread,
Aug 1, 2008, 4:37:17 AM8/1/08
to Lennart Borgman (gmail), 6...@emacsbugs.donarmstrong.com, r...@gnu.org, xah lee, bug-gn...@gnu.org, ya...@gnu.org

Joe Wells

unread,
Aug 4, 2008, 7:11:20 AM8/4/08
to xah lee, Yavor Doganov, 6...@emacsbugs.donarmstrong.com
xah lee <x...@xahlee.org> writes:

> The proposed change doesn't actually effect elisp code. It is primarly
> esthetic in nature.

This is not true. There are many places in the Emacs Lisp code which
recognize the M- and C- notation.

First, there is the read syntax (I'm using Emacs 22.1):

?\M-A ⇒ 134217793
?\M-\C-b ⇒ 134217730

"\M-A" ⇒ "\301" (yes, this is a bit different behavior for M-A)

Then, there is the convention of making symbol names with prefixes for
use in key bindings:

M-f3
M-mouse-1
M-drag-mouse-2
M-double-mouse-2

Then, there is the lovely kbd macro for use in key bindings:

(kbd "C-M-<down>") ⇒ [C-M-down]

Then, there is the use of the M- and C- notation by edit-kbd-macro.

Then, there are the key-description, single-key-description, and
read-kbd-macro functions:

(key-description [?\M-3 delete]) ⇒ "M-3 <delete>"

There is also the text-char-description function.

--
Joe


--
Heriot-Watt University is a Scottish charity
registered under charity number SC000278.

Lennart Borgman (gmail)

unread,
Aug 4, 2008, 7:38:10 AM8/4/08
to Joe Wells, 6...@emacsbugs.donarmstrong.com, xah lee, Yavor Doganov
Joe Wells wrote:

> xah lee <x...@xahlee.org> writes:
>
>> The proposed change doesn't actually effect elisp code. It is primarly
>> esthetic in nature.
>
> This is not true. There are many places in the Emacs Lisp code which
> recognize the M- and C- notation.

Thanks Joe for this list.

I am thinking about the possibility to just change what is shown in
menus and help texts (see my earlier reply to Xah's bug report). Such a
change would of course be optional, but might help new users.

With such a change there would of course be a steop for new users when
they are just frustrated because they do not understand how to do key
bindings, "why does not (kbd "Alt-<down>") work?", etc.

And the manual would probably better still use the current notation
(with a note about the new notation) because it is static and is read on
different platform. So everything would not be better, but the initial
treshold would probably be lower.

Can you see any technical trouble with the changes I am suggesting could
be done?

xah lee

unread,
Aug 4, 2008, 7:33:01 AM8/4/08
to Joe Wells, Yavor Doganov, 6...@emacsbugs.donarmstrong.com
The change suggested is only about in emacs manual, emacs tutorial,
and in menus.

There is no proposal to change emacs lisp's keyboard macro or elisp
functions.

Xah
http://xahlee.org/

On Aug 4, 2008, at 4:11 AM, Joe Wells wrote:

xah lee <x...@xahlee.org> writes:

> The proposed change doesn't actually effect elisp code. It is primarly
> esthetic in nature.

This is not true. There are many places in the Emacs Lisp code which


recognize the M- and C- notation.

First, there is the read syntax (I'm using Emacs 22.1):

?\M-A ⇒ 134217793
?\M-\C-b ⇒ 134217730

"\M-A" ⇒ "\301" (yes, this is a bit different behavior for M-A)

Then, there is the convention of making symbol names with prefixes for
use in key bindings:

M-f3
M-mouse-1
M-drag-mouse-2
M-double-mouse-2

Then, there is the lovely kbd macro for use in key bindings:

(kbd "C-M-<down>") ⇒ [C-M-down]

Then, there is the use of the M- and C- notation by edit-kbd-macro.

Then, there are the key-description, single-key-description, and
read-kbd-macro functions:

(key-description [?\M-3 delete]) ⇒ "M-3 <delete>"

There is also the text-char-description function.

--
Joe



0 new messages