unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Kangas <stefan@marxist.se>, xah lee <xah@xahlee.org>
Cc: 1111@debbugs.gnu.org
Subject: bug#1111: describe-key's key notation display inconsistency
Date: Thu, 8 Aug 2019 08:47:45 -0700 (PDT)	[thread overview]
Message-ID: <d5739584-8ac3-4fd5-be6e-7fb14899414c@default> (raw)
In-Reply-To: <CADwFkm=KKxsEZ40GJHDOP1_u8eaQih-DsSLYXrapaZb-YCgZLw@mail.gmail.com>

> > When doing a describe-key on C-<backspace>, emacs prints <C-
> > backspace> instead. Similar for any other special key whose macro
> > notation are bracketed by angle brackets. e.g. <down>, <F6>,
> > <return>, <kp-1>, etc. Where, emacs puts the entire thing inside
> > angle brackets instead of the more traditional of modifier
> > followed by dash followed by key name.
> >
> > Although these are identical as far as kbd function is concerned,
> > but wouldn't it be more intuitively consistent by using C-<key>
> > instead of <C-key>?
> 
> Would anyone else want to weigh in on this old wishlist item?  Is this
> a good idea, even if it is very minor, or should we close this as
> wontfix?
> 
> FWIW, I personally don't mind either way.

Dunno whether this is really weighing in, but...

I've said before (not in this thread, most likely)
that I think that the Emacs manuals should use the
exact same notation that Emacs itself uses
interactively.

That means the manuals should use <C-return>, not
C-<return>.  But they don't.

As for "the more traditional": we shouldn't care.
(I don't.)  Emacs should do what is best for Emacs.

The consistency we should look for is local, i.e.,
within Emacs.  Eli has defended the use of the
C-<return> notation in the manuals, so so be it:
we'll continue to live with that inconsistency
(relatively minor) in how Emacs talks about itself.

But at least interactively we should remain
consistent.  And there can be arguments in favor of
the <C-return> notation, even beyond the obvious
one that Emacs has long, long used it, so that
there is now no doubt code that expects and depends
on it.

My vote is not to change from <C-return> to
C-<return>.  (And my vote would be to always use
the former, even in the manuals.)

---

FWIW, I've also argued that we do not need
angle-bracket notation at all.  We can drop it and
still be completely unambiguous and consistent.
(I proposed this long ago, but it was rejected.)

IOW, instead of `C-x M-<delete>' we can use just
`C-x M-delete' - always.

I even have a library, `naked.el', that lets you
optionally get the angle-bracket-less notation,
except for places I can't control(e.g. C code):

https://www.emacswiki.org/emacs/NaKeD





  reply	other threads:[~2019-08-08 15:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-07 15:12 bug#1111: describe-key's key notation display inconsistency xah lee
2019-08-08 12:35 ` Stefan Kangas
2019-08-08 15:47   ` Drew Adams [this message]
2019-08-08 16:03     ` Noam Postavsky
2019-08-08 17:25       ` Drew Adams
2019-08-08 18:06         ` Noam Postavsky
2019-08-08 22:15           ` Drew Adams
2019-08-08 23:05             ` Noam Postavsky
2019-08-09  0:14               ` Drew Adams
2019-08-09  6:38                 ` Eli Zaretskii
2021-09-24 22:00 ` Stefan Kangas
2021-09-24 22:49   ` bug#1111: [External] : " Drew Adams
2021-09-26  5:07   ` Xah Lee

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=d5739584-8ac3-4fd5-be6e-7fb14899414c@default \
    --to=drew.adams@oracle.com \
    --cc=1111@debbugs.gnu.org \
    --cc=stefan@marxist.se \
    --cc=xah@xahlee.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).