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#37485: 27.0.50; C-m in describe-bindings Date: Mon, 23 Sep 2019 10:29:15 -0700 (PDT) Message-ID: <60aa8a60-237e-49b6-8807-9d5ca37a381f@default> References: <87sgooroa4.fsf@gnus.org> <83k19zpwtx.fsf@gnu.org> <8736gnb8mk.fsf@gnus.org> <83h853ouqi.fsf@gnu.org> <87ftknym8v.fsf@gnus.org> 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="220343"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 37485@debbugs.gnu.org To: Lars Ingebrigtsen , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 23 19:30:26 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 1iCSAL-000vC5-SA for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Sep 2019 19:30:25 +0200 Original-Received: from localhost ([::1]:60278 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iCSAK-0003F8-0A for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Sep 2019 13:30:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42073) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iCSA0-0003Es-Me for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2019 13:30:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iCS9z-0006Rm-7g for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2019 13:30:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56442) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iCS9y-0006R6-TR for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2019 13:30:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iCS9y-0002R7-Mi for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2019 13:30: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: Mon, 23 Sep 2019 17:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37485 X-GNU-PR-Package: emacs Original-Received: via spool by 37485-submit@debbugs.gnu.org id=B37485.15692597679297 (code B ref 37485); Mon, 23 Sep 2019 17:30:02 +0000 Original-Received: (at 37485) by debbugs.gnu.org; 23 Sep 2019 17:29:27 +0000 Original-Received: from localhost ([127.0.0.1]:37030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iCS9O-0002Ps-Om for submit@debbugs.gnu.org; Mon, 23 Sep 2019 13:29:27 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:56876) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iCS9L-0002Pe-VE for 37485@debbugs.gnu.org; Mon, 23 Sep 2019 13:29:25 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x8NHIq2g031559; Mon, 23 Sep 2019 17:29:17 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=My3rz/t7m6POsT/raLfXJsg4fN5uHGi9yY9dMCM6A9c=; b=lPPRvwflj80wB+OBkPHRyRuSH2tRmRezu24fFLck4UolJPlMG23DJOg3nN6wypHxfahH jIilHFA0y9Jiz49BSQtl9b3CDAg2WJI4b6zBuZXW7lW5QszM6Q8KEWIaOFnRaAVPB5yI EVZt7njZDYy3CtY0S6ttOS79pxbxUDRnev6sVQGRGzOl/T8G+Hvlsr5GOiIDrGeCCkZx 9cl0npBcbgHF7GbWQM5Lw86+9qVECFgAz22LL5jaBcSHS//ZuAKtARV1dNzlOlFr0aQ5 TV8gdx2maGGKM5FqX/auYENvv4clxb98tJFf352kSMRQpn0c/+18px0KDwEXHSsvMXPv ew== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 2v5btprgv4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Sep 2019 17:29:17 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x8NHHrdF063440; Mon, 23 Sep 2019 17:29:17 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 2v6yvn9y7c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Sep 2019 17:29:17 +0000 Original-Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x8NHTFxk022681; Mon, 23 Sep 2019 17:29:16 GMT In-Reply-To: <87ftknym8v.fsf@gnus.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4888.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9389 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-1908290000 definitions=main-1909230156 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9389 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909230156 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:167032 Archived-At: > But do you use RET instead of `C-m' in these keystrokes because that's > what `describe-bindings' say or because you prefer to hit `RET'? >=20 > Anyway, I've grepped through the *.texi files, and there are 152 matches > for `C-c C-m ...' and 8 for `C-c RET'. And all of those 8 are for RET > as the final character in the keystroke. >=20 > If you expand to "C-. C-m"/"C-. RET" it's 170/20. (All those additional > ones are from mule.texi.) >=20 > It seems the mode writers' intentions are pretty clear: They mean for > the users to type C-c C-m ..., but `describe-bindings' tells them to type > C-c RET. My 2c: If we show only C-m then users might not realize that they can use RET. If we show only RET then users might not realize they can use C-m. That's the way it goes. In the _doc_ (e.g. *.texi) we can always remind users that the two are equivalent (but not always equivalent to ). In particular, we can do that for a key binding that uses it after another C- key (e.g. after C-c). But in C-m, C-b, etc., we should provide the same key-description format, systematically. It would be confusing to sometimes use C-m and sometimes RET in such contexts. That could give users the false idea that the two are different. Emacs has always used RET in this case (key listings). And in most cases the key is not used as a prefix key, and it does not follow a C- key. And most users (I think) will recognize and use RET for such cases, even if they use C-m after a C- key or as a prefix key. So I'd vote for keeping RET in such lists of key descriptions. But I'd agree that it can help to point out, in doc, that you can use C-m as an alternative. Pointing that out is especially useful in a context where the key follows a C- key, and possibly even where it does not but it is used as a prefix key. So "the mode writers" you mention aren't necessarily wrong. But it would be wrong to change key listings, which are not specific to a given mode, to use C-m. You might say that `C-h m' is all about documenting the _mode_, so its output should reflect what "the mode writers" use. If that's the point then the mode description (doc string) can simply add a sentence reminding users that C-M =3D RET. Such a case is not a good reason not to keep key listings consistent.