From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thibaut Verron Newsgroups: gmane.emacs.devel Subject: Re: Concern about new binding. Date: Tue, 2 Feb 2021 21:02:55 +0100 Message-ID: References: <20210202134950.vybbpf3iewbymfjo.ref@Ergus> <20210202134950.vybbpf3iewbymfjo@Ergus> <878s86tnv6.fsf@red-bean.com> <875z3amhgg.fsf@red-bean.com> Reply-To: thibaut.verron@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16714"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Ergus , emacs-devel@gnu.org To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 02 21:05:56 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 1l71vs-00049c-Hs for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Feb 2021 21:05:52 +0100 Original-Received: from localhost ([::1]:50336 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l71vr-0007ZV-Jf for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Feb 2021 15:05:51 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43248) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l71t5-0005tP-JJ for emacs-devel@gnu.org; Tue, 02 Feb 2021 15:03:00 -0500 Original-Received: from mail-yb1-xb2d.google.com ([2607:f8b0:4864:20::b2d]:40228) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l71t3-0006jp-5A for emacs-devel@gnu.org; Tue, 02 Feb 2021 15:02:59 -0500 Original-Received: by mail-yb1-xb2d.google.com with SMTP id i71so8128600ybg.7 for ; Tue, 02 Feb 2021 12:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jRdrYdF9Kh0QuE30yb1iwyr8EpPRL0ppiNOAt1/tdYs=; b=WdByrBPn55lOht4Y7ozgODUeKlDwuraY+0Kr98TX5NI3MtLj3zDSQIRtUGoxcc0iuR t2OqAasrJz/VfzCrNsneQuNFuhaieQa1aQRkMJl4sAegOv4LoISTeUFTQ3fBXfAvhS0P c0+Z2T/iPtoUGG/SL1AubeH0o4aC+RuK6iHrBva94YMveZR86eEAdN9WH4ZoPvARM+CR 6mmoxy0DJN+OJz53yutT4ljhfXwlr2mXJ9Rxf3fnychWWCKv+XCeu9MOle/K4JfLYgeX +lqkfCStWwjiCyq5aYh/R8PvYdvMVqBWhICQHLs+qDFFa7GH1/Pfl5H1S/8xVonTLaMK 4AWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=jRdrYdF9Kh0QuE30yb1iwyr8EpPRL0ppiNOAt1/tdYs=; b=ZsfDV0/g74VQzrqazMMIaeKShyZ44bXlG8V2OP/8JyU1cBFAIFZnCBaCNBx3zhyuIJ 0dVlqCljfwfuwdLZhjSpG1/go0wgBVKwW4CNiiDhcyiKko7aC7Vgt+lJ7QU0i9TnWYoe gvaKqWnvOQ7nM3vlHjFTU31FaN5nVDQ3sHwRxqBtHqvjYnlS+88xLfonNM92s6DIoVtp eRI6UNIhKNpNQE7QWwpJBxYO0fP72e2aElkQSU3u8JVajQx0Ugvzl27Y31iZPkYza09h k9Vymxz1GCFy6Nli07MI8R4cMQ+d9yND8hAk1FIEi4Zjk1uP5i3PDSu1988tjHkVfe9s U9ZA== X-Gm-Message-State: AOAM530GGbnWFwugjdWNqEPLjRYTFExPKC/WMRfI1b25bw88lSPw9ds5 Dg2Rtlt4blZkBfH19cYDmWiF3Lw71NUwmm9TN3M= X-Google-Smtp-Source: ABdhPJwREH2xjOEe4+ATQJh6nAAqLue2tdtHh7ChUlLD1zExBePxGKdhMM4GVQxNFlFbfNMvPjCXX9LEt9MpwXby6w8= X-Received: by 2002:a25:ae98:: with SMTP id b24mr15698307ybj.183.1612296176029; Tue, 02 Feb 2021 12:02:56 -0800 (PST) Original-Received: by 2002:a05:7110:6187:b029:31:9798:b166 with HTTP; Tue, 2 Feb 2021 12:02:55 -0800 (PST) In-Reply-To: <875z3amhgg.fsf@red-bean.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::b2d; envelope-from=thibaut.verron@gmail.com; helo=mail-yb1-xb2d.google.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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:263750 Archived-At: 2021-02-02 19:51 UTC+01:00, Karl Fogel : > On 02 Feb 2021, Thibaut Verron wrote: >>2021-02-02 17:50 UTC+01:00, Karl Fogel : >>> On 02 Feb 2021, Ergus wrote: >>> 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. My bad, sorry. > >>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. If a key space is reserved *for future usage*, that's most definitely something I would expect to see mentioned in the key binding conventions. I mean, isn't the point of having written conventions precisely to avoid relying on "everyone knows that"? My understanding until today was that C-x is indeed crowded, but that the few remaining keys are free. > I mean, the guidelines don't say to avoid rebinding the letter `a' > either, but people know not to do that :-). Because 'a' is already bound. In modes where self-insert-command makes no sense, a can be bound. And some modes also sensibly rebind some keys away from self-insert-command (typically for delimiters insertion). Some packages also rebind C-<, C-a or mouse-click. And let's not get started about evil... > 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. Or they also took the guidelines and the convention at face value, acknowledging the status of C-c letter, but not mentioning anything about any emacs-reserved space. :)