GNU bug report logs - #1111 describe-key's key notation display inconsistency Previous Next Package: emacs; Reported by: xah lee xahlee.org> Date: Tue, 7 Oct 2008 15:20:03 UTC Severity: wishlist Tags: fixed Fixed in version 28.1 Done: Stefan Kangas marxist.se> To reply to this bug, email your comments to 1111 AT debbugs.gnu.org. There is no need to reopen the bug first. Toggle the display of automated, internal messages from the tracker. View this report as an mbox folder, status mbox, maintainer mbox Report forwarded to bug-submit-list lists.donarmstrong.com, Emacs Bugs gnu.org>: bug#1111; Package emacs. Full text and rfc822 format available. Acknowledgement sent to xah lee xahlee.org>: New bug report received and forwarded. Copy sent to Emacs Bugs gnu.org>. Full text and rfc822 format available. Message #5 received at submit emacsbugs.donarmstrong.com (full text, mbox): From: xah lee xahlee.org> To: bug-gnu-emacs gnu.org Subject: describe-key's key notation display inconsistency Date: Tue, 7 Oct 2008 08:12:48 -0700 When doing a describe-key on C-, emacs prints instead. Similar for any other special key whose macro notation are bracketed by angle brackets. e.g. , , , , 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- instead of ? Thanks. Xah ∑ http://xahlee.org/ ☄ Severity set to `wishlist' from `normal' Request was from Chong Yidong stupidchicken.com> to control emacsbugs.donarmstrong.com. (Tue, 07 Oct 2008 17:05:07 GMT) Full text and rfc822 format available. Information forwarded to bug-gnu-emacs gnu.org: bug#1111; Package emacs. (Thu, 08 Aug 2019 12:36:02 GMT) Full text and rfc822 format available. Message #10 received at submit debbugs.gnu.org (full text, mbox): From: Stefan Kangas marxist.se> To: xah lee xahlee.org> Cc: bug-gnu-emacs gnu.org, 1111 debbugs.gnu.org Subject: Re: bug#1111: describe-key's key notation display inconsistency Date: Thu, 8 Aug 2019 14:35:23 +0200 xah lee xahlee.org> writes: > When doing a describe-key on C-, emacs prints backspace> instead. Similar for any other special key whose macro notation are > bracketed by angle brackets. e.g. , , , , 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- instead of ? 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. Thanks, Stefan Kangas Information forwarded to bug-gnu-emacs gnu.org: bug#1111; Package emacs. (Thu, 08 Aug 2019 12:36:02 GMT) Full text and rfc822 format available. Information forwarded to bug-gnu-emacs gnu.org: bug#1111; Package emacs. (Thu, 08 Aug 2019 15:49:01 GMT) Full text and rfc822 format available. Message #16 received at 1111 debbugs.gnu.org (full text, mbox): From: Drew Adams oracle.com> To: Stefan Kangas marxist.se>, xah lee xahlee.org> Cc: 1111 debbugs.gnu.org Subject: RE: bug#1111: describe-key's key notation display inconsistency Date: Thu, 8 Aug 2019 08:47:45 -0700 (PDT) > > When doing a describe-key on C-, emacs prints > backspace> instead. Similar for any other special key whose macro > > notation are bracketed by angle brackets. e.g. , , > > , , 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- > > instead of ? > > 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 , not C-. 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- 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 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 to C-. (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-' 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 Information forwarded to bug-gnu-emacs gnu.org: bug#1111; Package emacs. (Thu, 08 Aug 2019 16:04:01 GMT) Full text and rfc822 format available. Message #19 received at 1111 debbugs.gnu.org (full text, mbox): From: Noam Postavsky gmail.com> To: Drew Adams oracle.com> Cc: xah lee xahlee.org>, 1111 debbugs.gnu.org, Stefan Kangas marxist.se> Subject: Re: bug#1111: describe-key's key notation display inconsistency Date: Thu, 08 Aug 2019 12:03:42 -0400 Drew Adams oracle.com> writes: > 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 , not > C-. But they don't. Having Emacs print C-, as suggested in the OP, would also solve the consistency, yes? I think it's a bit more readable, so I would be in favour of that. > --- > > 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. That assumes all function key names are longer than one letter, right? Information forwarded to bug-gnu-emacs gnu.org: bug#1111; Package emacs. (Thu, 08 Aug 2019 17:26:02 GMT) Full text and rfc822 format available. Message #22 received at 1111 debbugs.gnu.org (full text, mbox): From: Drew Adams oracle.com> To: Noam Postavsky gmail.com> Cc: xah lee xahlee.org>, 1111 debbugs.gnu.org, Stefan Kangas marxist.se> Subject: RE: bug#1111: describe-key's key notation display inconsistency Date: Thu, 8 Aug 2019 10:25:08 -0700 (PDT) > > 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 , not > > C-. But they don't. > > Having Emacs print C-, as suggested in the OP, > would also solve the consistency, yes? Yes, of course. At the cost of a lot of code changes, not to mention user mind changes. ;-) [We could also change Elisp to use only M-expressions, not S-expressions (sexps) - e.g. car('(1 2)) instead of (car '(1 2)), to more closely fit syntax expectations outside Lisp.] https://en.wikipedia.org/wiki/M-expression > I think it's a bit more readable, so I would > be in favour of that. To me it's less readable, but tastes vary. `C-x ' is noticeably different from `'. `C-x ' is not so noticeably different from `C- (to me, at least). --- > > 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. > > That assumes all function key names are longer > than one letter, right? Yes. But we already have the symbol for the corresponding event, which presumably has the same potential problem. E.g., the event that corresponds to the key described as `' is the symbol `right' (no angle brackets). The event that corresponds to the key described as `' is `M-f3'. Presumably the key described as `' (or `M-', per Xah), where `' is a function key, would correspond to event `M-d', which might already be problematic (no?). (And we would anyway distinguish function keys `' and `' via the bracket syntax, as `[M-d]'. It would only be the (proposed) standard key description where naked `d' and `M-d' could be ambiguous.) We could also make it explicitly conventional for a function key (including a fake function key, for a menu item) to have more than one character. We have no such convention, AFAICT, but have you ever come across a single-char function-key name? Or we could just leave `d' ambiguous, in the rare case that there might be an `d' function key as well as the `d' character key. I'd bet that there are no such anomalous function keys today (or in the past). Do you know of any? And do we even know whether all of Emacs works OK with such a function key? Anyway, going naked ain't gonna happen. That's been made clear. BTW, since Emacs 22, `single-key-description' takes an optional arg NO-ANGLES, which does what you might expect. Here is the reason given (in (elisp) `Describing Characters'): If the optional argument NO-ANGLES is non-'nil', the angle brackets around function keys and event symbols are omitted; this is for compatibility with old versions of Emacs which didn't use the brackets. (I don't think angle brackets are ever used around event symbols, so I'm guessing that "and event symbols" is wrong, there.) Information forwarded to bug-gnu-emacs gnu.org: bug#1111; Package emacs. (Thu, 08 Aug 2019 18:07:02 GMT) Full text and rfc822 format available. Message #25 received at 1111 debbugs.gnu.org (full text, mbox): From: Noam Postavsky gmail.com> To: Drew Adams oracle.com> Cc: xah lee xahlee.org>, 1111 debbugs.gnu.org, Stefan Kangas marxist.se> Subject: Re: bug#1111: describe-key's key notation display inconsistency Date: Thu, 08 Aug 2019 14:06:24 -0400 Drew Adams oracle.com> writes: >> > 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 , not >> > C-. But they don't. >> >> Having Emacs print C-, as suggested in the OP, >> would also solve the consistency, yes? > > Yes, of course. At the cost of a lot of code > changes, not to mention user mind changes. ;-) I don't think the code change would be that large (but we've not seen a patch yet). >> > 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. >> >> That assumes all function key names are longer >> than one letter, right? > > Yes [...] > Presumably the key described as `' (or > `M-', per Xah), where `' is a function > key, would correspond to event `M-d', which > might already be problematic (no?). I don't think so, (kbd "M-d") => [?\M-d], but (kbd "") => [M-D]. > but have you ever come across a single-char > function-key name? No (and I didn't mean to say that assuming all function key names are multi-character is unreasonable). Information forwarded to bug-gnu-emacs gnu.org: bug#1111; Package emacs. (Thu, 08 Aug 2019 22:17:01 GMT) Full text and rfc822 format available. Message #28 received at 1111 debbugs.gnu.org (full text, mbox): From: Drew Adams oracle.com> To: Noam Postavsky gmail.com> Cc: xah lee xahlee.org>, 1111 debbugs.gnu.org, Stefan Kangas marxist.se> Subject: RE: bug#1111: describe-key's key notation display inconsistency Date: Thu, 8 Aug 2019 15:15:46 -0700 (PDT) > > Presumably the key described as `' (or > > `M-', per Xah), where `' is a function > > key, would correspond to event `M-d', which > > might already be problematic (no?). > > I don't think so, (kbd "M-d") => [?\M-d], > but (kbd "") => [M-D]. I'm talking about the _event_. The value of the event is a symbol. In both cases (I think) it would be the symbol `M-d'. > > but have you ever come across a single-char > > function-key name? > > No (and I didn't mean to say that assuming > all function key names are multi-character > is unreasonable). (I didn't expect that you did mean that.) My point (in this tangent discussion) is that it is possible to drop the angle brackets. And the result would be a lot less noise. But unless we also added a convention such as no single-char function-key names, there could be some rare ambiguity. One way to avoid that rare case of ambiguity would be to use angle brackets only for the case of single-char names. Information forwarded to bug-gnu-emacs gnu.org: bug#1111; Package emacs. (Thu, 08 Aug 2019 23:06:02 GMT) Full text and rfc822 format available. Message #31 received at 1111 debbugs.gnu.org (full text, mbox): From: Noam Postavsky gmail.com> To: Drew Adams oracle.com> Cc: xah lee xahlee.org>, 1111 debbugs.gnu.org, Stefan Kangas marxist.se> Subject: Re: bug#1111: describe-key's key notation display inconsistency Date: Thu, 08 Aug 2019 19:05:31 -0400 Drew Adams oracle.com> writes: > > The value of the event is a symbol. I don't understand where you're getting that idea from. (info "(elisp) Keyboard Events"): There are two kinds of input you can get from the keyboard: ordinary keys, and function keys. Ordinary keys correspond to (possibly modified) characters; the events they generate are represented in Lisp as characters. Information forwarded to bug-gnu-emacs gnu.org: bug#1111; Package emacs. (Fri, 09 Aug 2019 00:16:01 GMT) Full text and rfc822 format available. Message #34 received at 1111 debbugs.gnu.org (full text, mbox): From: Drew Adams oracle.com> To: Noam Postavsky gmail.com> Cc: xah lee xahlee.org>, 1111 debbugs.gnu.org, Stefan Kangas marxist.se> Subject: RE: bug#1111: describe-key's key notation display inconsistency Date: Thu, 8 Aug 2019 17:14:44 -0700 (PDT) > > The value of the event is a symbol. > > I don't understand where you're getting that idea from. > (info "(elisp) Keyboard Events"): > > There are two kinds of input you can get from the keyboard: > ordinary keys, and function keys. Ordinary keys correspond to > (possibly modified) characters; the events they generate are > represented in Lisp as characters. We're not talking about ordinary keys. We're talking about function keys. They're not represented as characters. They're represented as Lisp symbols. (elisp) `Function Keys': Function keys are represented in Emacs Lisp as symbols; the symbol's name is the function key's label, in lower case. For example, pressing a key labeled generates an input event represented by the symbol 'f1'. (Note: not the symbol `' - see my statement that I think the doc that says that the angle brackets are part of the event name is incorrect, per this doc passage.) The event type of a function key event is the event symbol itself. See Classifying Events. ... the symbol for the key with held down is `M-f3'. Similarly, in (elisp) `Classifying Events' it talks about event types also being symbols: ... the event type for a function key symbol is the symbol itself. "Function key symbol", there seems to be the symbol talked about in `Function Keys'. So function keys and their events and the event types are all "represented in Emacs Lisp by symbols". Likewise, event modifiers are symbols. Information forwarded to bug-gnu-emacs gnu.org: bug#1111; Package emacs. (Fri, 09 Aug 2019 06:39:01 GMT) Full text and rfc822 format available. Message #37 received at 1111 debbugs.gnu.org (full text, mbox): From: Eli Zaretskii gnu.org> To: Drew Adams oracle.com> Cc: xah xahlee.org, 1111 debbugs.gnu.org, stefan marxist.se, npostavs gmail.com Subject: Re: bug#1111: describe-key's key notation display inconsistency Date: Fri, 09 Aug 2019 09:38:38 +0300 > From: Drew Adams oracle.com> > Cc: xah lee xahlee.org>, 1111 debbugs.gnu.org, > Stefan Kangas marxist.se> > > (elisp) `Function Keys': > > Function keys are represented in Emacs Lisp as > symbols; the symbol's name is the function key's > label, in lower case. > > For example, pressing a key labeled generates > an input event represented by the symbol 'f1'. > > (Note: not the symbol `' - see my statement that > I think the doc that says that the angle brackets > are part of the event name is incorrect, per this > doc passage.) You are mixing keys with events produced by those keys and with the description of those keys and events. They are all different. Information forwarded to bug-gnu-emacs gnu.org: bug#1111; Package emacs. (Fri, 24 Sep 2021 22:01:01 GMT) Full text and rfc822 format available. Message #40 received at 1111 debbugs.gnu.org (full text, mbox): From: Stefan Kangas marxist.se> To: xah lee xahlee.org> Cc: 1111 debbugs.gnu.org Subject: Re: bug#1111: describe-key's key notation display inconsistency Date: Fri, 24 Sep 2021 15:00:31 -0700 tags 1111 fixed close 1111 28.1 thanks xah lee xahlee.org> writes: > When doing a describe-key on C-, emacs prints > instead. Similar for any other special key whose macro notation are bracketed by > angle brackets. e.g. , , , , 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- instead of ? This is now the case in Emacs 28, from NEWS: ** Modifiers now go outside angle brackets in pretty-printed key bindings. For example, 'RET' with Control and Meta modifiers is now shown as 'C-M-' instead of ''. Either variant can be used as input; functions such as 'kbd' and 'read-kbd-macro' accept both styles as equivalent (they have done so for a long time). I'm therefore closing this bug report. Added tag(s) fixed. Request was from Stefan Kangas marxist.se> to control debbugs.gnu.org. (Fri, 24 Sep 2021 22:01:02 GMT) Full text and rfc822 format available. bug marked as fixed in version 28.1, send any further explanations to 1111 debbugs.gnu.org and xah lee xahlee.org> Request was from Stefan Kangas marxist.se> to control debbugs.gnu.org. (Fri, 24 Sep 2021 22:01:02 GMT) Full text and rfc822 format available. Information forwarded to bug-gnu-emacs gnu.org: bug#1111; Package emacs. (Fri, 24 Sep 2021 22:50:01 GMT) Full text and rfc822 format available. Message #47 received at 1111 debbugs.gnu.org (full text, mbox): From: Drew Adams oracle.com> To: Stefan Kangas marxist.se>, xah lee xahlee.org> Cc: "1111 debbugs.gnu.org" <1111 debbugs.gnu.org> Subject: RE: [External] : bug#1111: describe-key's key notation display inconsistency Date: Fri, 24 Sep 2021 22:49:27 +0000 > This is now the case in Emacs 28, from NEWS: > > ** Modifiers now go outside angle brackets in pretty-printed key > bindings. > For example, 'RET' with Control and Meta modifiers is now shown as > 'C-M-' instead of ''. Either variant can be > used > as input; functions such as 'kbd' and 'read-kbd-macro' accept both > styles as equivalent (they have done so for a long time). Unfortunate. Should have instead made the manuals consistent with the way Emacs has (forever) talked about itself, if consistency was the aim. (Internal / local consistency is always more important than global consistency. This will require at least some 3rd-party docs (HTML, wiki, plain-text, whatever) to change, where such bindings are explicit (not via \\[...]). And as I mentioned in this thread, it will lead users to misread and confuse things like `C-x ' with `C-'. There's no such problem with `'. ___ Beyond that, if the change is what was requested by the OP, then it's a change in *Help* (perhaps among other things). And yet that's not even mentioned in the NEWS. What does "in pretty-printed key bindings" refer to? Users will rightfully wonder. The manuals? (No, they already used C-.) Output of `pp' commands? Messages? Byte-compiler warnings? All of the above? None of the above? This bug report was last modified today. Previous Next GNU bug tracking system Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.