From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#17362: 24.4.50; inconsistent key notation: `ESC' vs `' Date: Tue, 29 Apr 2014 10:27:03 -0700 (PDT) Message-ID: References: <<47b1a857-a5d6-4e5a-b8f6-f96f9e201c89@default>> <> <> <<83fvkwmagn.fsf@gnu.org>> <<4294927c-08b3-4c65-83e4-1582e8d0d859@default>> <<838uqom7lm.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1398792517 30599 80.91.229.3 (29 Apr 2014 17:28:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Apr 2014 17:28:37 +0000 (UTC) Cc: 17362-done@debbugs.gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 29 19:28:30 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WfBpV-0005iM-Lo for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Apr 2014 19:28:29 +0200 Original-Received: from localhost ([::1]:51505 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfBpU-0008WS-Rl for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Apr 2014 13:28:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfBpD-0008P7-Vl for bug-gnu-emacs@gnu.org; Tue, 29 Apr 2014 13:28:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WfBp5-0005O0-1C for bug-gnu-emacs@gnu.org; Tue, 29 Apr 2014 13:28:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfBp4-0005Nw-Sv for bug-gnu-emacs@gnu.org; Tue, 29 Apr 2014 13:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WfBp4-0003aR-91 for bug-gnu-emacs@gnu.org; Tue, 29 Apr 2014 13:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Apr 2014 17:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17362 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17362-done@debbugs.gnu.org id=D17362.139879243613718 (code D ref 17362); Tue, 29 Apr 2014 17:28:02 +0000 Original-Received: (at 17362-done) by debbugs.gnu.org; 29 Apr 2014 17:27:16 +0000 Original-Received: from localhost ([127.0.0.1]:45317 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WfBoJ-0003ZB-2E for submit@debbugs.gnu.org; Tue, 29 Apr 2014 13:27:15 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:35484) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WfBoF-0003Ys-Rd for 17362-done@debbugs.gnu.org; Tue, 29 Apr 2014 13:27:12 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s3THR5B8003119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Apr 2014 17:27:06 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3THR3OI028921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2014 17:27:04 GMT Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3THR3jc015384; Tue, 29 Apr 2014 17:27:03 GMT In-Reply-To: <<838uqom7lm.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:88445 Archived-At: > > Eli, are you saying that you have replaced , , etc. > > everywhere with , , etc., or that you think it is > > appropriate to do so? >=20 > Only for BACKSPACE (and, of course, only in the manual). It's still > "Delete" (because that's the label on the key). ESC and TAB and SPC > and RET were always in caps, so they stay in caps. is not how Emacs refers to the key in help. And neither is . Emacs help calls these and , AFAICT. > > Seems like that would be a big change from the past and a change from > > how Emacs itself communicates with users. AFAIK, Emacs writes > > for the Delete key etc. The rule for function keys and pseudo function > > keys has always been to use lowercase (in angle brackets), no? >=20 > Yes, because they are symbols. I did nothing about symbols, of > course. What does that mean? Why write these key sequences differently in the manual from how Emacs writes them in help? Emacs writes . Why write ? Emacs writes . Why write Delete or ? > > You will perhaps say that refers only to the keyboard key, and > > not to an Emacs key sequence. >=20 > I'm not sure I understand what you mean by "an Emacs key sequence". > How does it differ from TAB the key? You are the one who has always reminded me that the manual writes keyboard keys differently from how it writes key sequences. I'm concerned only with the latter. If for you there is now no difference, great - then it's only about how the manual writes key sequences. My point is that the manual should write key sequences the same way Emacs writes them interactively, e.g., in help output. It does not refer to a key or a Backspace key or a , , Control, or Ctrl key. Emacs help writes and C- in key sequences. > Again, I only changed how keys are referenced in the manual in the > context of documenting keybindings. That's what we're talking about. (But key sequences as documented, not just "keybindings", which can be defined using a multitude of Elisp formats/sexps.) > > And I would have thought that the keyboard keys would anyway be > > written the same as they are on the keyboard: Tab, Backspace, Delete, > > Esc, not , , , . >=20 > On ma[n]y keyboards, TAB and BACKSPACE have no labels, and the > traditional DEL key didn't have one, either. I agree that nowadays > the situation is not 100% clear, but I simply chose to go with > tradition in these cases. I think Emacs has changed its "tradition" over time. In Emacs 20 there are no angle brackets in the UI, for instance (there are some in the manual). Emacs 20 help writes `next', not `' (as now). And neither Emacs 20 nor Emacs 24 help output writes `' (as appeared in the Emacs 20 manual) or `' (as appears in the manual now). `describe-key' outputs `C-x ', but the manual writes `C-x '. Go figure. Help writes `', `', `', and `'. But the manual writes `', `C-', and `' (capitalized). This is gratuitous confusion. Emacs has a well-defined way of representing key sequences - `kbd' is based on it. Why not use this single, well-defined syntax in the manual as well as the interactive help? It is pretty clear that for Emacs help output `TAB' is not the same thing as `'. The latter is a (pseudo) function key; the former is `C-i'. Why should the manual write ? > > 1. The way Emacs talks to users, via `kbd', `edmacro-parse-keys', and > > help output in general should not be changed. > > > > 2. The doc (manual) should follow the same conventions as `kbd', > > `edmacro-parse-keys' and help output in general. > > > > I am more concerned about #1 than #2. I don't actually see you > > proposing any change wrt #1 so far, which is good. >=20 > I didn't propose and didn't change anything under #1. As for #2, I > think it's impossible to satisfy that without changing significantly > how we describe keys in the manual. Dunno what that means. But having the manual in sync with interactive Emacs (e.g. help) would simplify things, not complicate them. For both Emacs maintainers and Emacs users, once the change is made. > > I do not, however, see a good reason why Emacs doc (manuals) should > > represent key sequences differently than Emacs help does. That kind > > of goes against Occam's razor, multiplying things unnecessarily. >=20 > No reason but history and Texinfo style guidelines. Sounds like a cop-out, to me - but please tell me I'm wrong. Do you even agree that key sequences should be written the same way in the manual as in the rest of Emacs? Do agree that the manual, like the rest of Emacs, should write and not C-, and not C-?