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 09:21:20 +0000 Message-ID: <5588fb25805d486be704@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> 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="16083"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 05 10:23:57 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 1l7xLH-00043K-5K for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Feb 2021 10:23:55 +0100 Original-Received: from localhost ([::1]:35042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7xLG-0006kH-69 for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Feb 2021 04:23:54 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34940) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7xIs-0004HP-29 for emacs-devel@gnu.org; Fri, 05 Feb 2021 04:21:26 -0500 Original-Received: from heytings.org ([95.142.160.155]:37582) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7xIp-0000Qh-Hd for emacs-devel@gnu.org; Fri, 05 Feb 2021 04:21:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1612516881; bh=cB6lQflJx8VOifXOI1DsARVW9UJRSu6suesbnkBaDsA=; h=Date:From:To:Subject:In-Reply-To:Message-ID:References:From; b=bypGhiCUIfXMI+H5kSplM3lCbuEhU3pD5lgaCVe7IMalchLQ8aH5mqZioo2/OFD4d AKh1pTR9UUjrv8jV8YNADF+ASqsuc9zrSsL2+ma7Qr2LBbOxIF3Z2t5uOHZUBgJzaR Mvyak2oULXjZLOXaVQn7Kvoo8/iEYpbX/PpdZEA9020pofefsy2fl2AKS/MPm5XpY6 4aqjnEfwoveOUO9xwpih5sUI1K2oWjhvd/7rQyRgcSG5Sp45sgTcPeeC/1zr8kEwmo 0sU8HA0vgoZtD0Rmoyy+hf1Dmqg7nxMhfndMMONXAiTi8g4hWWlftWUTQUR2JzCR4X Cronovy2h/igw== In-Reply-To: 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:263957 Archived-At: It seems to me that the root problem of this thread, and similar ones in the past months, is the lack of a convention for external packages in `(elisp) Key Binding Conventions'. There is a convention for users, there are conventions for major and minor modes, but there is no convention for external packages such as Magit, Drew's packages, and so forth. Consequently, the only solution for such packages is to use the currently empty slots, with a sword of Damocles hanging over them: these empty slots could at any time be reclaimed by Emacs. I too can sympathize with Drew's (and other's) frustration when this happens. 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". IOW, one could for example reserve either "C-z" (weak version), or "C-z" and "M-z" and "C-M-z" (strong version), for external packages. This is a one-time change, which I'm sure will not be an easy one for everyone, but is a long-term solution that will avoid such repeated wars.