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>, Drew Adams <drew.adams@oracle.com>
Cc: 17362@debbugs.gnu.org
Subject: bug#17362: 24.4.50; inconsistent key notation: `ESC' vs `<ESC>'
Date: Tue, 29 Apr 2014 12:09:25 -0700 (PDT)	[thread overview]
Message-ID: <d035db75-bf2f-4a7e-bca3-684f76f17742@default> (raw)
In-Reply-To: <<834n1cm1bx.fsf@gnu.org>>

> > > > > > 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?
> > > > >
> > > > > Yes, because they are symbols.  I did nothing about symbols, of
> > > > > course.
> > > >
> > > > What does that mean?
> > > Which part is unclear?
> >
> > Apparently you agree that the rule for function keys is lowercase.
> > Yet you leave some of them capitalized or uppercase?  And the reason
> > is because those that you make lowercase are symbols?
> 
> They are symbols used in Lisp code, whereas the other kind are words
> used in the user documentation.

I understand.  Emacs itself speaks with one voice here, however, which
is less confusing for users, IMO.

Users, especially non-Lispers, should not be concerned with whether a
given key name corresponds to a Lisp symbol.  They should not need to
know or guess that you call a key <Delete> because you feel that
"Delete" is sufficiently common as the name printed on the keyboard
key, even though Emacs refers to that key as <delete>.

And you write <left>, using the Lisp symbol name `left', because what
is printed on the keyboard key is an arrow, not "Left".  And yet for
<next>, the manual refers to it as both <next> and <PageDown> (in
Emacs 20 it was referred to as (only) <NEXT>).

These are inconsistencies within the manual, IMO.  They complicate
understanding unnecessarily.

It would be much clearer to refer to these keys, in key sequences,
always as <delete>, <left>, and <next>.  Nothing prevents the manual
from also saying that such keys might be labeled "Delete", "<--"
(using an actual arrow symbol in the manual), and "PageDown".  But
such names should not appear in key sequences - in the manual or
anywhere else.

> > > > Emacs writes <backspace>.  Why write <BACKSPACE>?  Emacs writes
> > > > <delete>.  Why write Delete or <Delete>?
> > >
> > > See the guidelines I used to decide on names and capitalization, I
> > > tried to explain why I choose this or that convention.
> >
> > The convention used should be the one that Emacs itself uses to
> > write key sequences.
> 
> I disagree.  The manual should make it easier for the reader to
> identify the keys it talks about.  For that reason, using the keys'
> labels is IMO more useful and efficient than using their lowercase
> variants.

See above.  The manual can mention commonly used key labels, to help
users make connections.  But it makes little sense for the manual
to represent these keys differently in key sequences from the way
Emacs itself represents them.

> > > I only fixed inconsistencies in the manual, without any relation to
> > > what Emacs says in help mode.
> >
> > You fixed only some inconsistencies in the manual, but that is OK
> > for this bug report.  It is inconsistent to use <BACKSPACE> sometimes
> > and <Backspace> other times, <DELETE> and <Delete>, <left> and <Home>,
> > and so on.
> 
> There should be only these variants in the manual:
>   <BACKSPACE>  <Delete>  <left> <Home>
> 
> If you find others, please report them as documentation bugs.  I tried
> to fix them all, but maybe I missed some; it is a large manual.

There are lots of occurrences of <Backspace>.  And yes, it is a large
manual.  Keeping multiple representations only makes it more difficult
for people to correct and maintain the manual, I'm guessing.

Feel free to close this bug, and thanks for doing what fixing you
have done.  Every little bit helps.





       reply	other threads:[~2014-04-29 19:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<c30f764a-5327-47f4-8bf6-ef6ad993518d@default>
     [not found] ` <<834n1cm1bx.fsf@gnu.org>
2014-04-29 19:09   ` Drew Adams [this message]
2014-04-29 19:20     ` bug#17362: 24.4.50; inconsistent key notation: `ESC' vs `<ESC>' Eli Zaretskii
2014-04-29 19:24       ` 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] <<e9c40932-a5e6-4e19-ac69-5b656438a555@default>
     [not found] ` <<83bnvlo2fh.fsf@gnu.org>
2014-04-28 16:20   ` Drew Adams
     [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     ` 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
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
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=d035db75-bf2f-4a7e-bca3-684f76f17742@default \
    --to=drew.adams@oracle.com \
    --cc=17362@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.