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: Fri, 5 Feb 2021 11:51:36 +0100

2021-02-05 10:38 UTC+01:00, Joost Kremers <joostkremers@fastmail.fm>:
>
> On Fri, Feb 05 2021, Gregory Heytings wrote:
>> 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,
>
> Actually, there is another option, which AFAIK has been the unspoken "rule"
> for
> such cases: leave the binding up to the user.

+1 (as long as we are speaking both about emacs and packages)

But there seems to be technical reasons for a package wanting to set
its binding.


> What we're talking about here are basically applications that run inside
> Emacs.
> They have an entry point, i.e., a function that the user can run to start
> the
> application (some may have multiple entry points, but that doesn't change
> the
> argument), which users can bind as they see fit. That's what the `C-c
> <letter>`
> keys are for. I mean, even applications that come with Emacs (Gnus, Rmail,
> Ediff
> come to mind), don't have standard key bindings.

How do you define "applications"? Magit is very similar in its intent
to vc-mode, which does have a global binding.
A cursory look through global-map shows global bindings for functions
from abbrev, dabbrev, calc, eww, xref, 2C, vc. Are those applications?

> Perhaps a better way to update the documented key binding conventions is to
> add
> the rule that packages should generally not create global key bindings.

I personally find it useful when packages recommend key bindings. It
helps me understand what the package is for and how it can be used.

And if sufficiently many users follow the recommendation, I don't know
if the key should be considered free.

The only practical difference for the issue at hand is that Emacs
rebinding a recommended binding will not break configurations, instead
the new binding will be shadowed by the users' init files.

> Reserving keys for external packages won't solve the fundamental problem
> here:
> two external packages may still decide to use the same key bindings,
> causing
> similar conflicts for users that install both.

As far as I know there has never been any serious conflict of this
kind. Examples of popular packages which come to mind with global keys
are:
magit recommending/setting "C-x g"
expand-region recommending "C-,"
ace-jump recommending "C-;"
multi-cursors recommending the keys around "C-." (with the exception
of "C-,", which might be explained by the fact that it's the same
author as expand-region)
org-roam hijacking "C-x n"

Basically, it's been first-come-first-served in the community for a
while, and small packages not complaining when their binding was taken
by someone who became bigger.

It seems to work, and it doesn't seem to make a difference whether a
key is recommended or bound for that.



reply via email to

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