From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#1111: describe-key's key notation display inconsistency Date: Thu, 8 Aug 2019 10:25:08 -0700 (PDT) Message-ID: <0d832886-8112-4331-bd84-b9edbeac4398@default> References: <06D80DE1-FCD6-45BB-B2D9-A968F797971C@xahlee.org> <85mugj3aqp.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="143467"; mail-complaints-to="usenet@blaine.gmane.org" Cc: xah lee , 1111@debbugs.gnu.org, Stefan Kangas To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 08 19:26:10 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hvmB0-000bC9-3z for geb-bug-gnu-emacs@m.gmane.org; Thu, 08 Aug 2019 19:26:10 +0200 Original-Received: from localhost ([::1]:54256 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvmAy-0000PH-Qs for geb-bug-gnu-emacs@m.gmane.org; Thu, 08 Aug 2019 13:26:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34001) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvmAt-0000PA-QG for bug-gnu-emacs@gnu.org; Thu, 08 Aug 2019 13:26:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hvmAs-00032D-Ec for bug-gnu-emacs@gnu.org; Thu, 08 Aug 2019 13:26:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:32828) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hvmAs-000329-AX for bug-gnu-emacs@gnu.org; Thu, 08 Aug 2019 13:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hvmAs-0007Ux-3i for bug-gnu-emacs@gnu.org; Thu, 08 Aug 2019 13:26: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: Thu, 08 Aug 2019 17:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 1111 X-GNU-PR-Package: emacs Original-Received: via spool by 1111-submit@debbugs.gnu.org id=B1111.156528512028776 (code B ref 1111); Thu, 08 Aug 2019 17:26:02 +0000 Original-Received: (at 1111) by debbugs.gnu.org; 8 Aug 2019 17:25:20 +0000 Original-Received: from localhost ([127.0.0.1]:41649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hvmAC-0007U4-ER for submit@debbugs.gnu.org; Thu, 08 Aug 2019 13:25:20 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:41500) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hvmAB-0007Tr-8H for 1111@debbugs.gnu.org; Thu, 08 Aug 2019 13:25:19 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x78HIssU022585; Thu, 8 Aug 2019 17:25:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=Xuzmb4abTYEwyqCp0rEqWF99vGudtU1gi5ZHV/zjv3Y=; b=r6nG3KHTb0zFceuy8BAQmBr6/VkqQs1Jqg6pGCbo3CRiQUQXLGUk5lsyTjTIol0NzRs8 CazvHy1FwoThDdSoC0DZ+v8+ALK1MP5sPqNGwLihAhrx4J2bpAJKIuJt/jzvVhpafHYz cSNwqXzL1+yvPdXzeDG4hb+aP/Ef33zaaQkEbik3dGjkBa8ryOrQKBVdtJwvVt3rqQu0 4ThH4CImpHSuPxqnFio/2XibBsWQBa9c+E7dDo30TeEwVFBcUMFT94tszuPfDieEWr/S QxkinooJ4x5MFU/hLIlDm1wWmC0FIHuy/Wp+zlqYu33wo5nHnaX412ohao+KOfGbuX5c Gw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=Xuzmb4abTYEwyqCp0rEqWF99vGudtU1gi5ZHV/zjv3Y=; b=LnqinOCOk/2bHiEq8nGl339nlW0CSxfswu4rSpqlfjsk/ajTQtbOd8ZC+UFfJlB5rfxx m0DaL21OqDJpIdi27QdL+5hqsRj5SUue+oOj+eNbuRM2IycstuIpUJgaUu2jjqtOSjus CLqCxtFdW/va+IYuXYjbVGSA3SOtBH2arMS1zlMe70r6MsbAPCa5kx5OhFHnODAoTgXW kddEG76sttzmzU0VSZV0e+yr7pW6aUU0Br3V5M85/c9kBJa4jnUDvmAsgPaCpyQdGkdS EoYHNAT1JzwPzSMhV/BVEXXC1lCCr0bohnshNy6XkK2vvedb7EaHBaVv5d2ZuYgovTbB ow== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2u8hps2jad-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 08 Aug 2019 17:25:13 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x78HHcB4054416; Thu, 8 Aug 2019 17:25:12 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3030.oracle.com with ESMTP id 2u8pj83vbr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 08 Aug 2019 17:25:12 +0000 Original-Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x78HP9jM014488; Thu, 8 Aug 2019 17:25:09 GMT In-Reply-To: <85mugj3aqp.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4873.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9343 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908080155 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9343 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908080155 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.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" Xref: news.gmane.org gmane.emacs.bugs:164773 Archived-At: > > 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. >=20 > 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. >=20 > 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.)