[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Concern about new binding.
From: |
Thibaut Verron |
Subject: |
Re: Concern about new binding. |
Date: |
Tue, 2 Feb 2021 21:02:55 +0100 |
2021-02-02 19:51 UTC+01:00, Karl Fogel <kfogel@red-bean.com>:
> On 02 Feb 2021, Thibaut Verron wrote:
>>2021-02-02 17:50 UTC+01:00, Karl Fogel <kfogel@red-bean.com>:
>>> 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 <letter>" 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. :)
- RE: [External] : Concern about new binding., (continued)
- Re: Concern about new binding., Thibaut Verron, 2021/02/02
- Re: Concern about new binding., Karl Fogel, 2021/02/02
- Re: Concern about new binding.,
Thibaut Verron <=
- Re: Concern about new binding., Basil L. Contovounesios, 2021/02/02
- Re: Concern about new binding., Richard Stallman, 2021/02/05
Re: Concern about new binding., Gregory Heytings, 2021/02/02
Re: Concern about new binding., Ergus, 2021/02/02