unofficial mirror of bug-gnu-emacs@gnu.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:38:00 -0700 (PDT)	[thread overview]
Message-ID: <70552b88-0d96-470d-ae4d-237e3b884637@default> (raw)
In-Reply-To: <<8338gwlz7v.fsf@gnu.org>>

> > 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>).
> 
> I simply never saw a keyboard with a "next" key, so I don't know how
> it is labeled.  I left those as they were because of that.

<next> is how Emacs calls the "PageDown" key.  You did not leave that
as <next>.  Or maybe you meant that you left it as <PageDown> because
it is never labeled `next'?

> > These are inconsistencies within the manual, IMO.  They complicate
> > understanding unnecessarily.
> 
> They are not inconsistencies to me, because there's a reason for
> selecting each spelling, and I explained that reasoning.  Others are
> welcome to come up with different schemes, if they want, but I think
> in general too drastic changes should be avoided, because people are
> used to see "TAB" and "ESC".

TAB and ESC is also how Emacs (UI/help) refers to those, so no problem
there.

> > > 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.
> 
> If you mention the labels in just one place, it is as if you didn't
> mention them at all.  It's a large manual, and no one reads the
> section about why the keys are named like they are. 

Cross references.

> Most readers want
> to read what directly pertains to the subject they need now, and
> little else.  So the key sequences in the manual need to use a
> consistent naming scheme throughout, and not just in some obscure
> subsubsubsection.

The consistent naming scheme is the one Emacs itself uses.  It is
what users are used to seeing from Emacs.  It is what users will
see when they go back to the UI from the manual.

A "consistent" naming scheme that sometimes bases the name on a
key label and sometimes bases it on a Lisp symbol, and so on, is
unnecessarily complicated.  You can give a reasonable reason why
you named this or that key the way you did in the manual, but if
the reasoning has to go through multiple possibilities it is
unecessarily complicated.

Users should not need to know what the complicated rule is (or to
look it up, in the lone manual location where it is explained).
They should not wonder why sometimes this is done and sometimes
that, even if you have a good explanation for it.

> > > > > 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>
> 
> Sorry, that was incorrect: it should be <LEFT>, in all caps.  The
> others are correct.

On my keyboard, "Backspace" is as much a label as are "Delete" and
"Home".  And I have a pretty common, standard keyboard.  You will perhaps
argue that keyboards change over time and differ according to location.
Exactly.

The most that can and should be said wrt keyboard key labels is to give
some examples: `DEL' and <backspace> (which are not the same) are
sometimes labeled "Backspace".  <next> is sometimes labeled "Page Down".
<left> is sometimes labeled with a left-pointing arrow.  And so on.

If Emacs itself can refer to a key as <next> then so can the Emacs
manual.  Emacs does not jump up every time it writes <next> and say
that this key might be labeled "PageDown", "Page Down", or "PageDwn"
on your keyboard.  And neither should the manual.  It is enough to
have a short section of the manual that talks about this - key labels
vs Emacs key-sequence notation.

> > There are lots of occurrences of <Backspace>.
> 
> Before my changes, yes.  Now I see only one, in the Glossary.

OK.





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

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<d035db75-bf2f-4a7e-bca3-684f76f17742@default>
     [not found] ` <<8338gwlz7v.fsf@gnu.org>
2014-04-29 19:38   ` Drew Adams [this message]
2014-04-30  2:51     ` bug#17362: 24.4.50; inconsistent key notation: `ESC' vs `<ESC>' 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
     [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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=70552b88-0d96-470d-ae4d-237e3b884637@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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).