From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#30530: 26.0; Emacs manual: mention (1) user-reserved keys, (2) users can bind any keys Date: Sat, 24 Feb 2018 09:00:51 -0800 (PST) Message-ID: <529ae5d2-b5e8-40d1-aaa6-87a76003b8bc@default> References: <> <<83lgfi4qw2.fsf@gnu.org>> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1519491620 17392 195.159.176.226 (24 Feb 2018 17:00:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 24 Feb 2018 17:00:20 +0000 (UTC) Cc: 30530@debbugs.gnu.org To: Eli Zaretskii , Drew Adams , Nicolas Goaziou Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 24 18:00:16 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1epdBH-00040A-7q for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Feb 2018 18:00:15 +0100 Original-Received: from localhost ([::1]:50817 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1epdDH-0006uZ-Qq for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Feb 2018 12:02:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34184) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1epdD3-0006rt-Cl for bug-gnu-emacs@gnu.org; Sat, 24 Feb 2018 12:02:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1epdD0-0007qB-7S for bug-gnu-emacs@gnu.org; Sat, 24 Feb 2018 12:02:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51028) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1epdD0-0007q2-2Q for bug-gnu-emacs@gnu.org; Sat, 24 Feb 2018 12:02:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1epdCz-0000jy-Ki for bug-gnu-emacs@gnu.org; Sat, 24 Feb 2018 12:02:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 24 Feb 2018 17:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30530 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30530-submit@debbugs.gnu.org id=B30530.15194916642779 (code B ref 30530); Sat, 24 Feb 2018 17:02:01 +0000 Original-Received: (at 30530) by debbugs.gnu.org; 24 Feb 2018 17:01:04 +0000 Original-Received: from localhost ([127.0.0.1]:58925 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1epdC4-0000il-Aa for submit@debbugs.gnu.org; Sat, 24 Feb 2018 12:01:04 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:52804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1epdC1-0000iA-MN for 30530@debbugs.gnu.org; Sat, 24 Feb 2018 12:01:02 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w1OGvsds154137; Sat, 24 Feb 2018 17:00:55 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-2017-10-26; bh=D1VGTkkg/Ndz3hh24qqMIjRnRQluQXCozoeMnYhoRpw=; b=Q6FkKU//ZhNNcBe+6JtxZuJ55HCuP2Aryh1UUSkCgS7jbX7OarOq23qZbL/+PViP+aHg QDd6ccj3pvkIP0xR/YaiBGERKvdF/fBYq7Dbw7jzAQTQ5N7F+O9xa6Lx/Uj8czOhPBxG Y6f04u2YZ47cx+73IIl+GdoTS/lgtsXk0lraF3jVCRSvsdfdq0H0rbbKwXS4xazsgPQW Wv/jlPcYfoenLhb6N1zFsPupvKEUJBCr4rxQbvFyq2vxvn12d+y5Ij5wseUr69a83rn0 9vmChUP04XQaK6kYpQMmOSKtTKkcEWS0XG07FURwMTAiaKBWMySAObQZ//eYtr+28G6k Pw== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2gbbq580v9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 24 Feb 2018 17:00:55 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w1OH0scK003752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 24 Feb 2018 17:00:54 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w1OH0qcZ002541; Sat, 24 Feb 2018 17:00:53 GMT In-Reply-To: <<83lgfi4qw2.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4654.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8814 signatures=668680 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-1711220000 definitions=main-1802240225 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: 208.118.235.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:143636 Archived-At: > > Following up on the request by Nicolas Goaziou in bug #28263, please > > consider adding some information about the keys that users can bind. >=20 > I'm sorry, but I really don't understand the issue here, and I would > prefer not to re-read the long discussion in that bug report (and > expect not to be any wiser if I did). Can someone please summarize > the issue at hand? >=20 > > 1. Say that Emacs and 3rd-party Lisp libraries often bind keys, but tha= t > > some keys are specifically reserved, by convention, for users. Poin= t > > out which keys are reserved for users. >=20 > Users can bind _any_ keys, as you yourself say: But some users do not know that. Telling them that explicitly in the Emacs manual can help make it clear. > > 2. Make it clear that users can, in any case, bind ANY keys they want; > > they are not limited to binding user-reserved keys. In particular, > > users can rebind keys that Emacs or some 3rd-party library has alrea= dy > > bound. >=20 > Given this, what good will it do to say something about keys reserved > for users in the user manual? Lisp developers should know that, which > is why it is in the ELisp manual. Some users do not know that these are the "safest" keys to bind, because they are reserved for users. Knowing that can help them by focusing them on those keys, which are less likely to be in conflict with libraries. > > 3. State that after a user has bound a key, evaluating some Emacs code > > (including loading a Lisp library) might rebind that key if it is no= t > > reserved for users. This is the reason some keys are reserved for > > users: to prevent the bother of some non-user code overriding user > > key bindings. >=20 > How would this help users? What would they do to avoid that? It's not about avoiding it. It's about making users aware of how it works. They can act with more confidence and less confusion if they know that some keys are reserved for them and other keys they might bind risk being overridden by loading a library or turning on a mode. Less surprise and pondering "WTF is going on?". > Bottom line, I don't really understand the issue you are asking to be > solved. Did you check bug #28263? > The bug report is phrased as a list of instructions to be > executed, but that's not how bug reporting should work -- you should > describe the problem itself as well. The problem is that users do not necessarily have a good idea what keys they can bind (answer: any keys) and which keys Lisp libraries are likely to bind (answer: keys not reserved=20 or users). Users have been known to ask about such things. Stating clearly in the Emacs manual what the case is in this regard can help users - see above. If you still do not get it, and you still do not want to look at bug #28263, then feel free to close this bug. This bug report doesn't ask for a lot. It would be enough to state these two things in the Emacs manual: 1. That some keys are reserved for users, so that if you bind those there is little chance that if you later load some library or turn on a mode you will seem to lose those bindings you made. 2. You can nevertheless bind any keys. Just be aware of #1, so you are not surprised if some non-reserved key you have bound seems to have somehow later become co-opted. The keys that are reserved for users could be listed/described, or the Emacs manual could just link to their description in the Elisp manual. Users should have _some_ easy way of knowing which keys are reserved for their use.