emacs-devel
[Top][All Lists]
Advanced

[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. :)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]