From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: [External] : Re: not good proposal: "C-z " reserved for users Date: Sat, 13 Feb 2021 20:48:11 +0000 Message-ID: References: <7eccb0b5-8371-e34a-3371-09b75e1a385a@yandex.ru> (message from Dmitry Gutov on Fri, 12 Feb 2021 14:37:10 +0200) <877dnc4dwf.fsf@robertthorpeconsulting.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15557"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "joostkremers@fastmail.fm" , "help-gnu-emacs@gnu.org" To: Robert Thorpe , Dmitry Gutov Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 13 21:48:51 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lB1qT-0003uZ-D6 for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 13 Feb 2021 21:48:49 +0100 Original-Received: from localhost ([::1]:55670 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lB1qS-0007Wu-FB for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 13 Feb 2021 15:48:48 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44002) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lB1q6-0007Wg-C6 for help-gnu-emacs@gnu.org; Sat, 13 Feb 2021 15:48:26 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:59548) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lB1q3-0004uR-Hu for help-gnu-emacs@gnu.org; Sat, 13 Feb 2021 15:48:25 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 11DKjRf5160963; Sat, 13 Feb 2021 20:48:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2020-01-29; bh=/T6JdrZHgJCzojJae0b4F/+RGgny/TsnwJ4tC1Ekw2M=; b=t7pi1vPDf+42crFfwhYfvIm3S+rXRcHTkVr+kE8TZzI/xKQ2IO/TtcedVG9Z2UYDFZgl inqYaKRnb3wSkhlpkMty7HhtAS15ntUOUVxxoDUzezHiAOKVeHWbAZY4kPD6KTHZf2aJ nu4+/Rmf1/48gHA7oWj6GEdTGp+m8fPGo+uL38o1HyU/zGL5E2WpdsaFguhU2vTozqJN J1KdIBstBOcruMWd3Q0EuB/Hj8pyl3FJXmw+nDm7QtT+B5SSlBhBfSrtEUQsQOq4SjE2 nHiHJmMm9/fr3SuawMqbI6ezjiLaz2i59EcNxpMu60OWBqSKaLMGH/oTJ6CAudEVHAc9 MQ== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 36pd9a0gsh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 13 Feb 2021 20:48:14 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 11DKjmXl020837; Sat, 13 Feb 2021 20:48:14 GMT Original-Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2055.outbound.protection.outlook.com [104.47.37.55]) by userp3030.oracle.com with ESMTP id 36p6d9bkx1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 13 Feb 2021 20:48:13 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ni5qEZTJ5DjPFL2UhapOD/qhg75i3PvI05dB6uPgUfryfRkvCkEZDRHMAK1mis4sTJWE2n5jP2VEs16oW+E8NHpPWng4bTvYgmzNpjtDSG0AYSQ5JfFOy/KFGKGWtiSGcjVF16QDom3oV0ZJAloZY47Jaza/XHPoA8ENUwCnSbLkac0zU0H2qBRA9vOlamhJKrwqap0XJNXzJDQNN4uniJE/kjFlvvyanCNpkeo6difeF5AGtVSvGGRNmC4xPBfA091VefmJzjuKnzuMwd78dRI03rv5OIfUdVrLZEkwVJDKmgaVNInqUZ+XayvSRhK50FC1oWzlsWqAQSCh6lObDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/T6JdrZHgJCzojJae0b4F/+RGgny/TsnwJ4tC1Ekw2M=; b=C7cinkoG+qXA9PNic5ehEW/M3UE5LxYktfj9iSimF2SSH9JHgquBrXuK64MV2fACO6iPCA59aixH8gjSOKurs9nrNIIT4+JbBjxdkf8JoygmZ091OxQ7DxnLLTeNnEyElWyZS7Es2Ltv7vGp2/OjXr14mZXafld4XUoa82G7OMbKzIEjaWkAdnsQH+aaA9Zv+SC5GnvM2vxaXwhv8h2BkDNl12z8QNbCukEOzZkSeadlh/aKZ31JkuNYY1K4KfDCojETysSLKuJy9JFyTFJL0vbF6dajEUBSydnMklMzeVOGsh0ZAJ1Rsju9fYGo5Db2K4t2qAnP0iAJRi59j4B44Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/T6JdrZHgJCzojJae0b4F/+RGgny/TsnwJ4tC1Ekw2M=; b=alvc2fZLgbHPIRXlgGPo6BTvlJDdrXDQPcYCpfpfBl9iD3SyXoRlu0AjDz+0buk4D0cP/epEUQP/8HP8Sg/eziVZi4raUyXzS+ApMf53xBz9aJ9/twYkA6OeCyONp/5LUQziy516nW8Tlps2ZA7zSD3g9HSM6IYk6pcSwOuWkkE= Original-Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15) by SN6PR10MB2958.namprd10.prod.outlook.com (2603:10b6:805:db::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.36; Sat, 13 Feb 2021 20:48:12 +0000 Original-Received: from SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3846.038; Sat, 13 Feb 2021 20:48:12 +0000 Thread-Topic: [External] : Re: not good proposal: "C-z " reserved for users Thread-Index: AQHXAdslu0zP9UkW9keHyu3s+ubkZKpWgybw In-Reply-To: <877dnc4dwf.fsf@robertthorpeconsulting.com> Accept-Language: en-US Content-Language: en-US authentication-results: robertthorpeconsulting.com; dkim=none (message not signed) header.d=none;robertthorpeconsulting.com; dmarc=none action=none header.from=oracle.com; x-originating-ip: [73.170.83.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ee684799-c6bb-4395-5d48-08d8d060ad8d x-ms-traffictypediagnostic: SN6PR10MB2958: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5X37YD9seidLEkM9XR/cStJpJHuPwv+PwTEx07Rx+CsxZV4B10cza+kc+lt27ttDlWvpJwKHPlIl4FQm7+2s7248O8gl/JBEV317jDyBk8IjTbdNVvmMRD0fDj1Flac7lUigvsTdGolBTKx9TZ2ftjXLnUZTiCDZuCV+GEVqlSzpU06wRCso+Ck1JTlRldhqFN0SIdC/NZ0TqU9MaiUCLtk5f8u7OB0wicqgxjZ+v/QmkQoaajxZBy0ueY6YiZGR7WQFboNEVvCVH8A6UYVE4YgQ8Q9mnqG9z6RPQcESf4sHQn1bNiRDouTfh89lbocSPsUCC34G7odvzjSuf/sZ6wJ2bSH4nlIf6K20NrVwwc3dVoR7CZY/MCdTRM+Hb7ReBIF0/0Zmjtzsd7nE/hXOsofJRc7+9PRKLyLqnkEX4F0F0S7p3O5w/jYk4fsDC4JgPwOpiei4IO4wRLl/wLO+PuvWMOKESIYz0u/sFA8K4B9idsTl3BwspslKO5Z8WiWIe+eHB4iuG2KrhCsVf+/o2MMR1XtV8XneQitlYN6gUSgWAL1IDKL9NPf8bibeiJfIGJHd5omBul9KKyCEt/m1TQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(346002)(376002)(136003)(39860400002)(52536014)(186003)(26005)(66476007)(66446008)(7696005)(76116006)(66946007)(66556008)(64756008)(4326008)(86362001)(5660300002)(83380400001)(8676002)(71200400001)(316002)(44832011)(478600001)(2906002)(54906003)(110136005)(9686003)(55016002)(6506007)(33656002)(8936002)(19860200003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?2yp7nWCzgBbH/zG0i7dfxnOATGQUooIpMsv1/mLqz3eD5ScCmwHMKrpw+pkS?= =?us-ascii?Q?FGN10KIbCB+OnEQRrDyJWeBlWZbUpVP14rEHSvMNyVC/hITOO7sNPuW+Yygz?= =?us-ascii?Q?jTQrFojtsx5ShP1zQgxJILc/qdED2G1f1w/KiHkmQeZQHo6x3Bwc2ey7nLq6?= =?us-ascii?Q?6oZBcRSNr0AmgYJKHkBsfhIHn+o/9XuXYa+T32d84S4tYkPHWgUawl30i604?= =?us-ascii?Q?eL7DL632HXtui6uK8vj07yj9f3hSaFIw8sfrAHRbuK+m7P1qPQZ+1YuDsB5D?= =?us-ascii?Q?c+Dkx3mp37ujHuWxuzKQvz3X5kqniQ0p8+hW3qLRG0jcktwQy5+ddZMYxmIA?= =?us-ascii?Q?oIgUtBGk73I/6ojcP1+oRn8+e7q0j8Sgjb3Z1tljB7b4ufzX5PzRyELXpNqk?= =?us-ascii?Q?GT/MWMgOTY1J3Frv04DZKchUGHHfxoG/SG8Se14kqpxg5bUMoy+uGIZXDeCL?= =?us-ascii?Q?SQM6CmhkgAvFJVuj7KVeMICjTuW9H8ZJxWFrOK1+kPWmPGhIRlVJo+QoFZeh?= =?us-ascii?Q?PEFegjZ/5Vqdt+IoeqHzINjffbBEbiLBCK2vYgDnY5YkyCjFKxsBBYRrGOrL?= =?us-ascii?Q?Yj1WLQ8QQjeIATl31JxSvZJWGeuxGg7aSOIriaKQtaHuSgAc7cXwtBd/9qB6?= =?us-ascii?Q?YZeN x-ms-exchange-transport-forked: True X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ee684799-c6bb-4395-5d48-08d8d060ad8d X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2021 20:48:11.9209 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hR0b4Mq4XV8K0DQPhloy+OsQrIEhFTxkC8zVbN2VJLgfd2GUd8VHkMwS242AiUTk7VigqP/5YXdzKjxFobzSpw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR10MB2958 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9894 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 suspectscore=0 mlxscore=0 malwarescore=0 bulkscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102130193 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9894 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 impostorscore=0 mlxscore=0 phishscore=0 mlxlogscore=999 spamscore=0 bulkscore=0 priorityscore=1501 malwarescore=0 suspectscore=0 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102130193 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:127972 Archived-At: > >> I think that user-friendliness is beneficial. It would help with > >> that if packages could bind some keys by default. > > > > The current tradition is that a package provides a major or minor > mode > > (or several), puts one of them in their init file, and *those* > install > > some default keymaps. > > > > auto-mode-alist entries, however, can be added through autoloads. >=20 > Yes. But I don't think that solves the problems that Gregory Heyting > and Drew Adams are talking about. >=20 > Firstly, it can't do anything about changes in keybindings in future > Emacs versions. Drew tells us that Emacs has recently mapped "C-x x", > "C-x p" and "C-x /". I'm using Emacs 27.1, so all of those must have > been mapped for Emacs 28 (or perhaps the version after that). To be clear, my understanding, from following bug and emacs-devel threads, is as follows. Anyone can correct me if I'm mistaken in any way. 1. `C-x p' was recently grabbed as a prefix key for Project (by Dmitry, in fact) - over my pleas and arguments not to. That was maybe 8 months ago? Bookmark+ had, for many years, lots and lots of keys on that prefix key. The only arguments by Dmitry in favor of grabbing that key for Project were, in effect, (a) we want to do it and (b) we don't need to care what Bookmark+ has been using. OK. As a result of that, I changed Bookmark+ last July to use `C-x x' instead. (There was no mention of `C-x x' in that discussion, and it was unbound.) 2. Recently, Lars decided to bind `revert-buffer' to `C-x x g'. There was subsequent discussion about using that prefix key `C-x x' for things related to buffers, in general. I don't know exactly what's been done in that regard. Needless to say, I again objected, saying that I've moved Bookmark+ keys from prefix `C-x p' to `C-x x', and asking that they not now usurp also `C-x x'. But AFAIK, `C-x x' has, yes, now been grabbed by Emacs as a default global binding. (There was quite a lot of objection, BTW, to the idea that Emacs needs a _global_ key for reverting a buffer. I'm not even sure there was _anyone_ arguing in favor of that, besides the maintainer who came up with the idea.) 3. There was talk in emacs-devel (or a bug thread?) about binding `C-x /' by default. I don't know what finally happened in that regard. But I chimed in about that too, saying that I use that prefix key for zones.el. I mentioned this while pointing out there is a _general_ problem here: Emacs grabbing more keys for default bindings, leaving 3rd-party code with fewer and fewer options. 4. I'll mention too that for Bookmark+ when I changed from `C-x p' to `C-x x' I added a user option for which key to use. So users can deal with the new conflict themselves, if I don't end up trying yet another key as the default. > The author of a third party package can't easily > deal with that. What if their minor mode used > "C-x x"? In that case it will remove the keymaps > of a core feature (or the core feature will remove > it's keymap). Indeed. And the anecdotal stories from me are just that: one user's experience. There's a long history (future) in front of us. This problem will only become exacerbated. The field of keys that are not used by default Emacs is small and dwindling. And that, precisely at a time when the development of 3rd-party libraries is growing. We are no longer in the old Wild West days of a vast, open new continent to colonize. _Some_ solution is needed for this problem, which will only increase. _Because_ I objected recently, raising this as a general problem, there has been some discussion. But the main Emacs maintainer has declared that there is _no_ such problem. End of story, perhaps, but not, IMO, end of problem. I proposed one possible solution - a _moratorium_ by Emacs from grabbing more keys by default. Look up the word "moratorium", if you aren't familiar with it. If you like, you can consider my proposal to be: Let's at least STOP now from binding any more keys by default, while we entertain discussion for other possible solutions. And as long as no adequate solution, preferably somewhat consensual, is found, Emacs just shouldn't bind more keys. It can repurpose keys that are already bound by default, but it should stay away from binding new ones. And I explicitly allowed for _exceptions_, to be decided by the maintainers - after some general discussion. So IMO, this is not at all a radical proposal. It's essentially "STOP THE BLEEDING!" as a _first step_. > As Gregory Heyting has pointed out, what about > packages that are not modes? Not every package > is a minor mode or major mode. In fact, I'm pretty sure that most - maybe all - libraries are not simply implementations of a mode. Dealing with a mode, especially in terms of key bindings, isn't really problematic. Especially a minor mode. Sure, there can still be some key conflicts, but that's nothing new. Users juggle multiple minor modes already. > So, how should other types of package behave? >=20 > Lastly, the usability issue is still there. > I think beginners find this kind of thing difficult. > These days there are lots of Emacs "starter kits" > that claim to make Emacs simpler. A lot of what > they do is configuring third-party packages. >=20 > Philip Kaludercic suggested some code for prompting > users before mapping keys. I think that's a good idea. Maybe that could be part of a solution. But many users will not appreciate, or not be prepared for, making such key-binding decisions at the outset and on the fly. And prompting would likely be in some order, e.g., the first package loaded would prompt first, or the first prompt would occur when the first key conflict is detected. There are lots of details and things to consider. But I'm glad that at least some people are seriously considering the problem and starting to think about it. Unfortunately, the main threads in emacs-devel about this, kind of got hijacked by interjecting the possibility of changing some existing Emacs default key bindings. I specifically wanted to avoid that, or rather, to move that to a parallel, and longer discussion. I really would like to see us, FIRST, stop the bleeding by agreeing that Emacs should stop binding default keys while we figure things out and, SECOND, start discussing solutions in parallel, with less urgency, carefully. And that discussion can, yes, consider particular _existing_ key bindings and possibilities of refactoring Emacs default key bindings. But the first step should be to agree to stop the bleeding: "Emacs: hands-off new default keys, please."