emacs-devel
[Top][All Lists]
Advanced

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

angle-bracket notation for keys (was: Selection changes)


From: Drew Adams
Subject: angle-bracket notation for keys (was: Selection changes)
Date: Sat, 17 Jul 2010 18:54:28 -0700

> '<...-insertchar>' is very ugly and... unattractive!

And unnecessary.  `<S-tab>' etc. used to (sometimes) be written `S-tab' or
`S-TAB'.  But, sigh, function keys have always been written in Emacs (e.g. in
Info) using angle brackets, IIRC.  Even Emacs 20's Info uses `<F1>' to represent
the `f1' key, though it at least writes `f1' or f1 in *Help*.  Emacs 22 was
"improved" to make this consistent - consistently ugly.

The angle-bracket notation is unnecessary because multi-character key names such
as `delete' could be written just like that.  `delete', `C-delete', `C-delete
insert', `C-insert M-delete' etc.  This is an unambiguous notation, but we don't
use it, unfortunately.

We do sometimes represent user input by separating keys in a sequence with
whitespace, e.g. in instructions: "Type `h e l l o'".  But we are not consistent
in that, writing sometimes "Type `hello'" to also mean type those five keys.
And we still treat some keys differently, using angle brackets: "Type `hello
<S-tab>'" (where the space is not necessary but is typically present).

There is no ambiguity between `delete' and `d e l e t e', given consistent use
of the simple convention that whitespace separates keys in a sequence.  The
former is a single key named "delete"; that latter is a sequence of six keys.
It doesn't matter whether it's a new function key that you never heard of, `foo'
or one such as `delete' that is well-known.  The convention is crystal clear and
foolproof.  You know that `foo' means a key and `f o o' means a sequence of
three keys.

Even when multi-character key names are used in representations of user input
(e.g. instructions) there is no problem: "Type `C-insert  h e l l o  C-RET'".
Whitespace can be used to separate keystrokes this way because we have `SPC' to
represent hitting the space bar: "Type `d o g , SPC c a t'".

And sequences of many keys like that are relatively rare in the doc anyway, so
the admittedly less readable "Type `h e l l o'" (vs "Type `hello'") would not be
a big deal in practice.  And it's not just about the doc (Info).  It's also
about the UI: *Help*, messages, etc.  It's about the way Emacs talks about
itself.

If we used this simpler convention consistently, we would gain in clarity.  And
we would reduce the number of extra chars that just represent noise: <> plus a
space vs just a space.  `<f1> <S-tab> <C-delete>' vs `f1 S-tab C-delete'.  (A
no-brainer, wouldn't you say?)

Not to mention that all keys would be treated the same way - there is nothing
special about `f1' and `TAB' vs `a' and `C-a'.  There's no reason to write
`<f1>' and `<TAB>' but also write `a' and `C-a' (not `<a>' and `<C-a>').  The
angle brackets serve no useful purpose.  If they are noise in the case of
`<C-a>' then they are just as much noise in the case of `<f1>'.

And even though angle brackets separate keys (presumably that's their raison
d'etre), they are so ugly and unclear that we typically use whitespace as well!
We often write `<a> b <c>', not `<a>b<c>', even though the latter is also
unambiguous.  Why?  Because of the ugliness factor.  Because angle brackets are
not very readable.

Our convention uses at least two chars, and more often three, to separate two
keys - even when some of those key representations use angle brackets: `<a> <b>'
(3 chars: >, SPC, <).  This is just not necessary.

Anyway, no, I do not really intend to open this discussion again.  My suggestion
about this was rejected long ago.  I just wanted to say that (a) yes, what we
use is ugly, (b) it does not have to be that ugly, and (c) we've been around the
block on this question before.

If you are interested, see these old threads, which deal with the question in
some detail (examples, arguments, etc.):

http://lists.gnu.org/archive/html/emacs-devel/2005-10/msg00142.html

http://lists.gnu.org/archive/html/emacs-devel/2006-09/msg00732.html

http://lists.gnu.org/archive/html/emacs-devel/2006-09/msg00984.html

http://lists.gnu.org/archive/html/emacs-devel/2006-10/msg00213.html





reply via email to

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