From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg via Users list for the GNU Emacs text editor Newsgroups: gmane.emacs.help Subject: Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages Date: Tue, 09 Feb 2021 23:06:08 +0100 Message-ID: <871rdoj3qn.fsf@zoho.eu> References: <7e12c1c3c1aae58993e2@heytings.org> <8ed9b43502da52e07ff5@heytings.org> <8ed9b43502576d94a2c8@heytings.org> <8ed9b43502e36d186bcb@heytings.org> Reply-To: Emanuel Berg Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9993"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:lnI3WnmxsJgjjWPuyZUWg18UB/I= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 09 23:07:28 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 1l9bAO-0002Re-5G for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 09 Feb 2021 23:07:28 +0100 Original-Received: from localhost ([::1]:59074 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9bAN-0000CH-7W for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 09 Feb 2021 17:07:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46286) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9b9G-000053-J5 for help-gnu-emacs@gnu.org; Tue, 09 Feb 2021 17:06:18 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:52084) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9b9E-00005g-PI for help-gnu-emacs@gnu.org; Tue, 09 Feb 2021 17:06:18 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1l9b9B-00010Z-D5 for help-gnu-emacs@gnu.org; Tue, 09 Feb 2021 23:06:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:127748 Archived-At: Drew Adams wrote: >>> But no effort is needed for keys not yet bound - zero, >>> beyond documenting the fact. >> >> The effort, or the absence of effort, is not the important >> point here. > > You're the one who brought up the "effort" needed by Emacs > to carry out this or that proposed change. You claimed that > your proposal needed less effort. I argued that it needs > more effort (> zero). > > This was important enough that you brought it up. Now it's > not important. OK. > >> The main point is freedom: give more freedom to both Emacs >> and third- party libraries. And "documenting the fact that >> keys not yet bound cannot be bound anymore" hinders Emacs' >> freedom. I know, you also said that "exceptions would be >> possible with the approval of maintainers", but that's >> precisely what happened with the new "C-x x" key, and you >> objected anyway. > > Maintainers decide. I accept that - that's their role, > always, including on those occasions where I might disagree. > > The entire discussion was brought to emacs-devel - not by me > - from a bug thread, where `C-x x' was taken over willy > nilly, yes, over my objection. > > And the bug/enhancement request was much narrower. > The decision was to bind a _global_ key by default. > Gigantic overkill, for the narrow problem raised by the > bug report. > > I agreed (in emacs-devel, when discussed there, and in the > bug thread before that) that such wide decisions - wider > than the bug thread - should preferably follow wider > discussion in emacs-devel. > > Half of the discussion in emacs-devel was/is about this > problem that some big, wide-ranging change gets made in > a bug thread, without many eyes seeing it or minds > discussing it. That's a problem (IMO - the maintainers > disagree). > > Wrt the actual change made: > > I objected that, within the last year, first prefix key `C-x > p' was taken over, so I changed my code to use `C-x x' > instead, and now `C-x x' was also taken over. That's quite > a bit to lose in a year. And both changes were made in bug > threads - no discussion in emacs-devel. > > I objected to that, and I still object. It's not I who > decide, and that's fine. But my opinion that this isn't > a good change, and that such things should be discussed in > emacs-devel, remains. > > I'm not so worried as you about Emacs's "freedom" to bind > the keys it wants. Casting this as a question of "freedom" > is alarmist and ridiculous, IMO. This is a question about > what key-binding conventions we should have, nothing more. > >>> My proposal is to separate any and all such possible >>> default key-binding _changes_ from the simple act of >>> declaring the keys so far unbound by default to be >>> reserved for 3rd-party code. >> >> That just can't happen, it would be a arbitrary constraint >> that would impair Emacs' evolution, it would mean that >> hundreds of small or large potential improvements would not >> be possible anymore. > > Not at all. It would mean that Emacs would try harder not to > add new default key bindings. It's not trying hard enough > now - that's the problem. IMO, it's gotten worse lately, > when we can least afford it (available keys are scarcer and > scarcer). > > I asked for other solutions to the problem (still asking). > And the maintainer's reply was that there is no problem. > > Yes, you proposed another answer to the problem, and that's > fine. It's not as good an answer as mine, IMO, but at least > you offered something. > >>> I would welcome any such support, if that really is >>> your intention. >> >> FWIW, it was indeed really my intention. The proposal is an >> attempt to find a reasonable middle ground that would give >> as much freedom as possible to Emacs, as much freedom as >> possible to third-party library developers, and without >> changing users' habits too much. > > That's a good intention, though the ideas that this is about > "freedom", and that Emacs needs more "freedom" to add > default key bindings, are misguided, IMO. > > And as I said, by proposing to use a currently bound key for > this you increase, not decrease, the contention and argument > over which keys Emacs should "lose" to this, and you > increase, not decrease, the need for users to change habits. If only you could be passionate about it! But seriously now, I thought people had just got a bit crazy like they sometimes do, but reading this long post I realize I missed something... What has happened? Can anyone summarize it i one or to paragraphs instead of ~20? -- underground experts united http://user.it.uu.se/~embe8573 https://dataswamp.org/~incal