all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 17362-done@debbugs.gnu.org
Subject: bug#17362: 24.4.50; inconsistent key notation: `ESC' vs `<ESC>'
Date: Tue, 29 Apr 2014 08:40:52 -0700 (PDT)	[thread overview]
Message-ID: <4294927c-08b3-4c65-83e4-1582e8d0d859@default> (raw)
In-Reply-To: <<83fvkwmagn.fsf@gnu.org>>

>     - If a key does not have a label, its name should be in all caps,
>       as in @key{TAB} or @key{META}.
> 
>     - There are 2 exceptions to the last 2 rules, both for historical
>       reasons:
> 
>       * @key{BACKSPACE}, although many keyboards have a "Backspace"
>         label on it.
> 
>       * @key{ESC}, which is labeled "Esc".

Eli, are you saying that you have replaced <delete>, <backspace>, etc.
everywhere with <DELETE>, <BACKSPACE>, etc., or that you think it is
appropriate to do so?

Seems like that would be a big change from the past and a change from
how Emacs itself communicates with users.  AFAIK, Emacs writes <delete>
for the Delete key etc.  The rule for function keys and pseudo function
keys has always been to use lowercase (in angle brackets), no?

I thought that we used uppercase only for the ASCII control chars: TAB,
RET, ESC, and DEL, and not for key sequences involving pseudo function
keys <tab> and <backspace>.  (I also thought that we specifically did
NOT enclose the former in angle brackets, but I guess that's another
story.)

You will perhaps say that <TAB> refers only to the keyboard key, and
not to an Emacs key sequence.  In that case, it should not appear as
part of a key sequence notation, IMO.

And I would have thought that the keyboard keys would anyway be
written the same as they are on the keyboard: Tab, Backspace, Delete,
Esc, not <TAB>, <BACKSPACE>, <DELETE>, <ESC>.

It seems to me that:

1. The way Emacs talks to users, via `kbd', `edmacro-parse-keys', and
   help output in general should not be changed.

2. The doc (manual) should follow the same conventions as `kbd',
   `edmacro-parse-keys' and help output in general.

I am more concerned about #1 than #2.  I don't actually see you
proposing any change wrt #1 so far, which is good.

I do not, however, see a good reason why Emacs doc (manuals) should
represent key sequences differently than Emacs help does.  That kind
of goes against Occam's razor, multiplying things unnecessarily.

Let me know if I am misunderstanding something.  I admit to feeling
a bit confused now by the various notations.  I thought it was pretty
straightforward: just ASCII control char names (uppercase), function
keys and pseudo function keys (lowercase, in angle brackets).  It no
longer seems so straightforward and simple.





  parent reply	other threads:[~2014-04-29 15:40 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<47b1a857-a5d6-4e5a-b8f6-f96f9e201c89@default>
     [not found] ` <<CAH8Pv0i8RqY8JpPEurRycUwRp_C1_UZ5NN5MXwW3uQ74kYeQDQ@mail.gmail.com>
     [not found]   ` <<83fvkxo4kc.fsf@gnu.org>
2014-04-28 15:39     ` bug#17362: 24.4.50; inconsistent key notation: `ESC' vs `<ESC>' Drew Adams
2014-04-28 16:15       ` Eli Zaretskii
     [not found]   ` <<b73bc016-5fd5-4af5-879c-18c14a989a14@default>
     [not found]     ` <<83fvkwmagn.fsf@gnu.org>
2014-04-29 15:40       ` Drew Adams [this message]
2014-04-29 16:19         ` Eli Zaretskii
     [not found]       ` <<4294927c-08b3-4c65-83e4-1582e8d0d859@default>
     [not found]         ` <<838uqom7lm.fsf@gnu.org>
2014-04-29 17:27           ` Drew Adams
2014-04-29 17:51             ` Eli Zaretskii
2014-04-29 21:55               ` Josh
2014-04-29 23:00                 ` Drew Adams
2014-04-30  2:55                 ` Eli Zaretskii
     [not found]           ` <<f2425601-bc55-4f33-ba22-5a2045fdf78a@default>
     [not found]             ` <<8361lsm3b6.fsf@gnu.org>
2014-04-29 18:12               ` Drew Adams
2014-04-29 18:34                 ` Eli Zaretskii
     [not found] <<d035db75-bf2f-4a7e-bca3-684f76f17742@default>
     [not found] ` <<8338gwlz7v.fsf@gnu.org>
2014-04-29 19:38   ` Drew Adams
2014-04-30  2:51     ` Eli Zaretskii
     [not found] <<c30f764a-5327-47f4-8bf6-ef6ad993518d@default>
     [not found] ` <<834n1cm1bx.fsf@gnu.org>
2014-04-29 19:09   ` Drew Adams
2014-04-29 19:20     ` Eli Zaretskii
2014-04-29 19:24       ` Eli Zaretskii
     [not found] <<e9c40932-a5e6-4e19-ac69-5b656438a555@default>
     [not found] ` <<83bnvlo2fh.fsf@gnu.org>
2014-04-28 16:20   ` Drew Adams
2014-04-28 14:29 Drew Adams
2014-04-28 14:49 ` Dani Moncayo
2014-04-28 15:25   ` Drew Adams
2014-04-29 15:17     ` Eli Zaretskii
2014-04-28 15:29   ` Eli Zaretskii

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=4294927c-08b3-4c65-83e4-1582e8d0d859@default \
    --to=drew.adams@oracle.com \
    --cc=17362-done@debbugs.gnu.org \
    --cc=eliz@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.