From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Robert Thorpe Newsgroups: gmane.emacs.help Subject: Re: not good proposal: "C-z " reserved for users Date: Mon, 15 Feb 2021 04:49:45 +0000 Message-ID: <87y2fq540m.fsf@robertthorpeconsulting.com> References: <763e1864-b66b-be16-c6e5-d6a9bc3f0bbe@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32059"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joostkremers@fastmail.fm, help-gnu-emacs@gnu.org To: Dmitry Gutov Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 15 05:51:00 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 1lBVqe-0008Ec-IT for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 15 Feb 2021 05:51:00 +0100 Original-Received: from localhost ([::1]:56444 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lBVqd-000184-L6 for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 14 Feb 2021 23:50:59 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51014) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lBVq9-00016H-Dh for help-gnu-emacs@gnu.org; Sun, 14 Feb 2021 23:50:29 -0500 Original-Received: from outbound-smtp44.blacknight.com ([46.22.136.52]:60597) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lBVq2-0000Z5-1W for help-gnu-emacs@gnu.org; Sun, 14 Feb 2021 23:50:28 -0500 Original-Received: from mail.blacknight.com (pemlinmail01.blacknight.ie [81.17.254.10]) by outbound-smtp44.blacknight.com (Postfix) with ESMTPS id C5A25F804D for ; Mon, 15 Feb 2021 04:50:18 +0000 (GMT) Original-Received: (qmail 28977 invoked from network); 15 Feb 2021 04:50:18 -0000 Original-Received: from unknown (HELO rt-inspiron-3480) (rt@robertthorpeconsulting.com@[51.37.90.145]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 15 Feb 2021 04:50:18 -0000 In-Reply-To: <763e1864-b66b-be16-c6e5-d6a9bc3f0bbe@yandex.ru> (message from Dmitry Gutov on Sun, 14 Feb 2021 01:47:28 +0200) Received-SPF: pass client-ip=46.22.136.52; envelope-from=rt@robertthorpeconsulting.com; helo=outbound-smtp44.blacknight.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=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:128073 Archived-At: Dmitry Gutov writes: > On 13.02.2021 09:37, Robert Thorpe wrote: >> Dmitry Gutov writes: >> ... >> Yes. But I don't think that solves the problems that Gregory Heyting >> and Drew Adams are talking about. >> >> 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). > > Is that a problem? When such package finds out about a change like this, > they can change the default binding, or they might keep it as it was. I disagree. You're asking the authors of third-party packages to constantly respond to the capricious behaviour of the maintainers. I think they're likely to take their efforts elsewhere if that continues. I think Third party package authors should not have to do that. The maintainers of Emacs should provide a way to deal with the situation. > After all, the changes like the ones you have mentioned are additive, > both the project keymap and the later addition of buffer-related > commands on 'C-x x'. They haven't been there before, and a fair number > of users might not miss them if xyz-mode (which they do use) takes up > either of the sequences. Don't you think that's a suboptimal situation? Yes, it may be that some users never miss features. Perhaps lots of users never use your project features because they have already bound C-x p to something else. Equally well though, users may miss out on something that they would have found useful. I think it's better to do something about future collision up-front, to deal with them *before* more happen. >> 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). > > Minor mode keymaps generally override the global keymap. But not usually in a way that causes conflicts. Usually the keys that minor modes over-ride are not used by other things. In that past, when lots of development was in core Emacs managing key collisions was an internal job amongst the maintainers. Now there are thousands of 3rd-party packages on ELPA and MELPA. I don't think the hoping the muddling through will be OK is a good policy. >> As Gregory Heyting has pointed out, what about packages that are not >> modes? Not every package is a minor mode or major mode. So, how should >> other types of package behave? > > Depends on how their setup is documented. Minor or major modes are the > majority, though. > >> Lastly, the usability issue is still there. I think beginners find this >> kind of thing difficult. > > Having a key sequence overridden by a minor mode? > > Considering beginners don't usually read the manual, they might not even > know they are missing anything. Which might be a loss, of course, in > certain cases. But not a difficulty. I don't see the distinction. I think every loss is also a "difficulty". >> 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. >> >> Philip Kaludercic suggested some code for prompting users before mapping >> keys. I think that's a good idea. > > Some infrastructure for suggesting custom key bindings might work, but I > feel the current third-party tradition has held up pretty well. In my view what we've seen in this thread points the other way. It might have held up well in the past but it's showing it's age. BR, Robert Thorpe