Subject: Re: bug#17362: 24.4.50; inconsistent key notation: `ESC' vs `<ESC>'

From: Eli Zaretskii <[email-masked]>
Date: Wed, 30 Apr 2014 05:51:43 +0300

> Date: Tue, 29 Apr 2014 12:38:00 -0700 (PDT)
> From: Drew Adams <[email-masked]>
> Cc: [email-masked], [email-masked]
> 
> > > 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>.

Yes, I did leave it as <next>.

> > > > 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.

Doesn't help too much in this case.  You cannot ask people to go to
see that explanation each time they see a key sequence.

> > 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.

Not good enough: Emacs sometimes calls several keys by the same name.
This is OK for key binding, but not for user manual descriptions.

> 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.

Please read the manual, and tell me if this is needed.  I think
readers indeed will not wonder about any rules, because the text
speaks for itself, and so do the key names.  The rules are for those
who write the manual, and they are there to make the text speak for
itself.

> > > > 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.

Not exactly.  I explained why I decided to use BACKSPACE.  Please go
back and re-read that.

As the keyboards change, so does the Emacs manual in this area, by the
way.  So there's no need (and no practical way) to adopt a naming
scheme that would endure changes in keyboards.

> 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.

The manual already does that.

> 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.

The manual already does that, too.