From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: Concern about new binding. Date: Fri, 05 Feb 2021 12:07:48 +0000 Message-ID: <5588fb25800131ef8afa@heytings.org> References: <87zh0mmr54.fsf@gmail.com> <87y2g5smya.fsf@gmail.com> <4FF55FBF-573D-4A70-B3FC-682CA25B7ECB@gnu.org> <83lfc53whk.fsf@gnu.org> <20210203180142.seu6o3i6u7jhkyrh@Ergus> <83eehx3to5.fsf@gnu.org> <20210203221628.xgvvxjvh56gyswba@Ergus> <20210204070033.pm4ido4hq7a6twif@Ergus> <83sg6brhyg.fsf@gnu.org> <5588fb25805d486be704@heytings.org> <83pn1epxpd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9520"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 05 13:08:58 2021 Return-path: Envelope-to: ged-emacs-devel@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 1l7zv0-0002LR-CU for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Feb 2021 13:08:58 +0100 Original-Received: from localhost ([::1]:39054 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7zuz-00050v-Eu for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Feb 2021 07:08:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40336) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7ztx-0004YX-2N for emacs-devel@gnu.org; Fri, 05 Feb 2021 07:07:53 -0500 Original-Received: from heytings.org ([95.142.160.155]:37802) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7ztv-00084S-5Q; Fri, 05 Feb 2021 07:07:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1612526868; bh=42+j5h3HlGmmz1eD1yCi2UuXynjb16G9dVy4FjeszjI=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=ojX5pDEjIf9Ihq5zdEdYs+huF/Y+8FGaxayBRhHf8QvmMx2FReh5/pqn13bK2sFuF P2EcpUtlJwfGGpoxLvvRkJCPKFJQ52LxOIGN9Ma+Eo2tk3pNIieSRQ1hey0rtaWIGz Yc53CoQD2Cg0pvtVwZJ9hikztYfuSW54zqAOwIK3b4+tXb1z2X/zwsptvWH3etstfj DBpNcdvcGyj5oqBEVnHZS9LSI7lSN67yNtP471pn4pxE9R5bqjIAaZbel2CQ/fpZRV BNEa7cF6q0DIscPHRoyiPGXvqbZukTlCtWVGAb0i3Sxuw2A3pxFutUY/Qk4hZIjlkc OoQ6u3SBujV6Q== In-Reply-To: <83pn1epxpd.fsf@gnu.org> Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:263977 Archived-At: >> A proposal to solve the current problem and future similar problems is >> to free one of the keys, and to mention in `(elisp) Key Binding >> Conventions' that it is, forever, reserved for external packages. >> >> This proposal has two forms: a weak and a strong one. The weak one >> would only reserve the control key, the strong one would also reserve >> the meta and control-meta keys. >> >> The candidate keys for that proposal are "z", "t" and "o". > > C-z, C-t, and C-o are already taken > I know this; I said "to _free_ one of the keys". > > C-t in particular is very useful and frequently-used (by me, FWIW), and > also matches the default binding in Bash, GDB CLI, and elsewhere. A > recent discussion demonstrated that at least for C-z enough people are > against changing its binding, even though we have "C-x C-z" to do the > same. > Yes, it is unavoidable that some people will be against changing a binding. I have no preference between the three proposed keys, and anticipated that there would be more objections against using "t" for that purpose. If we put "t" aside, there are still two other options: "z" and "o". > > These data points suggest that usurping these keys may not be easy, to > say the least. > The meaning of the proposal is that the benefit of such a single change is, in the long term, largely superior to its loss in the short term.