From: "Drew Adams" <drew.adams@oracle.com>
To: "'Angelo Graziosi'" <angelo.graziosi@alice.it>,
"'David De La Harpe Golden'" <david@harpegolden.net>
Cc: 'Chong Yidong' <cyd@stupidchicken.com>, 'emacs' <emacs-devel@gnu.org>
Subject: angle-bracket notation for keys (was: Selection changes)
Date: Sat, 17 Jul 2010 18:54:28 -0700 [thread overview]
Message-ID: <F2FAB0D8A86F4210A042DD3D75C6921E@us.oracle.com> (raw)
In-Reply-To: <4C42418F.4060600@alice.it>
> '<...-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
next prev parent reply other threads:[~2010-07-18 1:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-16 1:00 Selection changes Angelo Graziosi
2010-07-16 9:33 ` David De La Harpe Golden
2010-07-17 23:49 ` Angelo Graziosi
2010-07-18 1:54 ` Drew Adams [this message]
2010-07-18 2:07 ` angle-bracket notation for keys Miles Bader
2010-07-18 3:05 ` angle-bracket notation for keys (was: Selection changes) Eli Zaretskii
2010-07-18 5:42 ` Drew Adams
2010-07-18 17:21 ` Eli Zaretskii
2010-07-18 19:15 ` Drew Adams
2010-07-18 22:05 ` angle-bracket notation for keys Harald Hanche-Olsen
2010-07-18 9:51 ` Angelo Graziosi
2010-07-18 19:28 ` Selection changes David De La Harpe Golden
2010-07-18 22:39 ` Angelo Graziosi
2010-07-16 12:14 ` Angelo Graziosi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F2FAB0D8A86F4210A042DD3D75C6921E@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=angelo.graziosi@alice.it \
--cc=cyd@stupidchicken.com \
--cc=david@harpegolden.net \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.