From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Concern about new binding. Date: Tue, 02 Feb 2021 12:51:11 -0600 Message-ID: <875z3amhgg.fsf@red-bean.com> References: <20210202134950.vybbpf3iewbymfjo.ref@Ergus> <20210202134950.vybbpf3iewbymfjo@Ergus> <878s86tnv6.fsf@red-bean.com> Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40218"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Ergus , emacs-devel@gnu.org To: Thibaut Verron Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 02 19:53:47 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 1l70o7-000ALA-5b for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Feb 2021 19:53:47 +0100 Original-Received: from localhost ([::1]:39522 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l70o6-00081G-7a for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Feb 2021 13:53:46 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56910) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l70lg-0005Am-V5 for emacs-devel@gnu.org; Tue, 02 Feb 2021 13:51:17 -0500 Original-Received: from sanpietro.red-bean.com ([45.79.25.59]:33578) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l70le-0004eR-Jr for emacs-devel@gnu.org; Tue, 02 Feb 2021 13:51:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=red-bean.com; s=202005newsp; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:Reply-To:References:Subject:Cc:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description; bh=u/Stu368OXRJftfxpoJij42Uqg7BZUlg+vhDa87Et0o=; t=1612291873; x=1613501473; b=ecFkli2aU2hFCZb/odl1TfTa5FNyKWNYcMvT1ENnBfxbflU13ok3jBSft6TaGgrj4xLH9HpEcd wogcMyB8HrmYk4820mkeCNJxpv31/GllXt7o0FigwQ7gShiYZoODBQok2dSoMwj0hIKusvBdPc2A6 Vyj6ZkWMBTUWJSQHAwLlptAhR07XS17vNbSP0ux2l8U4G1Sd3MTA7ZNSLVvq9PzxW5ozNwy61x3C2 fuuxPVN6Idb+2EtnZulaB44+zygShtcuUJXcMrGiqo3bZIPuXPtZzSiZuri63MZk0dojydXEc2zo0 DDBj2kcaAQHC2nfxz6U1UakYNZDF8myGTBCPg==; Original-Received: from 99-112-125-163.lightspeed.cicril.sbcglobal.net ([99.112.125.163]:37586 helo=floss) by sanpietro.red-bean.com with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l70lc-0000W4-Ua; Tue, 02 Feb 2021 18:51:13 +0000 In-Reply-To: (Thibaut Verron's message of "Tue, 2 Feb 2021 18:45:09 +0100") Received-SPF: pass client-ip=45.79.25.59; envelope-from=kfogel@red-bean.com; helo=sanpietro.red-bean.com 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:263738 Archived-At: On 02 Feb 2021, Thibaut Verron wrote: >2021-02-02 17:50 UTC+01:00, Karl Fogel : >> On 02 Feb 2021, Ergus wrote: >>>1) In general `C-x g` is used by magit; I know this is not a >>>priority (cause magit is an external package), but magit is a >>>very popular package. >> >> While Magit is indeed very popular and valuable, shouldn't it >> still adhere to convention and avoid binding things in the >> `C-x' space? >> >> That's really a point to be made on the Magit development >> mailing list, not here, but what I'm saying here is that Emacs >> shouldn't make special efforts to avoid interfering with >> package keybindings that violate Emacs's conventions anyway. >> >> Magit should instead suggest `C-c g' as an entry point for >> `magit-status', though a user can bind it however they want of >> course. I doubt there are any Magit users who would be daunted >> by the need to set up a keybinding for Magit's entry point. > To be clear, Magit itself does not bind anything by default. It >suggests "C-x g" as a binding, and I see now that it also offers >an option to enable that binding for the user. Actually, Magit does bind `C-x g' by default. There is a defcustom, `magit-define-global-key-bindings', and it defaults to `t' in magit.el since October 2020 -- see [1] for the history of that decision. When that variable is true, then that keybinding (and two others) are made automatically by Magit at load time. >It is not the only high-level package using "C-x letter" as an >entry point, another example coming to mind is projectile ("C-x >p"). As for the conventions, as far as I can tell, they >explicitly require to steer clear of "C-c letter", but they don't >have anything about "C-x letter": >https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html Uh, I mean... sure, okay, those guidelines don't say anything explicit about not binding `C-x LETTER' in your 3rd-party package, but does that kind of guidance really have to be made explicit? This is Emacs: everyone who develops for Emacs knows that the `C-x' map is crowded and used heavily by Emacs. If everyone's packages started binding things under there, they'd simply collide with *each other* all the time, as well as (eventually) with Emacs when Emacs decides to add a new `C-x' binding, as happened here. I mean, the guidelines don't say to avoid rebinding the letter `a' either, but people know not to do that :-). Magit should explicitly advise users to use `C-c LETTER' for Magit's entry points. The user-reserved space is there under `C-c LETTER' precisely so users can bind entry points to their favorite functionality. In other words, while Magit itself should "steer clear" of binding things under either `C-x' or `C-c LETTER', Magit is perfectly free to make recommendations. Right now, Magit's three main entry points are: C-x g `magit-status' C-x M-g `magit-dispatch' C-c M-g `magit-file-dispatch' And the doc string for `magit-define-global-key-bindings' even says the following: > We recommend that you bind "C-c g" instead of "C-c M-g" to > `magit-file-dispatch'. The former is a much better binding > but the "C-c " namespace is strictly reserved for > users; preventing Magit from using it by default. Now, clearly Magit's developers knew about the convention and decided to clobber the Emacs-reserved space anyway. I totally understand why they did so, even though I disagree with the decision. One solution to this would be for Emacs to reserve some keyspace for those three Magit entry points explicitly, outside the `C-c WHATEVER' conventions. Maybe it would be under `C-x', or maybe somewhere else. Magit is so popular that this might make sense -- essentially, bring Magit back into keybinding compliance by creating a reserved space for it. I'm not sure why Magit doesn't ship with Emacs; I presume it has something to do with copyright assignment issues. But I think the question of whether a package ships with Emacs can be, in principle, be independent of the question of whether Emacs reserves some keybinding space for that package. That might sound like a weird idea, but Magit is a good example of a situation where it could make sense. Best regards, -Karl [1] commit 5a38e1bb0fffa0326a1b5073c0ce9b05386e5109 Author: Jonas Bernoulli AuthorDate: Sat Oct 31 20:16:01 2020 +0100 Commit: Jonas Bernoulli CommitDate: Fri Nov 6 21:40:17 2020 +0100 Add three global key bindings by default For the longest time we have tried hard to avoid doing this but it is just not worth the effort and leads to an inferior result. Now we add three bindings by default. ;;;###autoload (when magit-define-global-key-bindings (let ((map (current-global-map))) (define-key map (kbd "C-x g") 'magit-status) (define-key map (kbd "C-x M-g") 'magit-dispatch) (define-key map (kbd "C-c M-g") 'magit-file-dispatch))) As you can see is easy to prevent these bindings from being added and I hope having to do so won't upset anyone too much. While we did not add global bindings we already added these bindings in all file-visiting buffers and we did not get any complaints about that. This completely replaces `magit-file-mode' and the global variant, which we define as an alias of the new variable. See #4237. M Documentation/magit.org M Documentation/magit.texi M lisp/magit-files.el M lisp/magit.el