Re: Concern about new binding.

[Joost Kremers <joostkremers@fastmail.fm>]

On Fri, Feb 05 2021, Gregory Heytings wrote:
>>
>> 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.
>>
>
> That's another solution indeed, but IMO it is not a reasonable one.  It is 
> reasonable for a package to create global bindings,

I tend to feel differently. :-) It's reasonable for a package to *suggest*
specific global key bindings and perhaps even to provide a user option or
function to install them, but IMHO they shouldn't be created automatically.

To an extent, this is just my personal opinion, but I think there are technical
reason as well. Firstly, note that `use-package` makes it possible to delay
loading a package until it's first used. That would be moot when creating
bindings depends on loading a package. In order to install the global bindings,
the package would have to be loaded upon startup. If you'd want to lazy-load a
package, you'd have to bind the keys explicitly anyway.

Moreover, lazy-loading makes it necessary that a package that creates its own
global bindings adds a user option to disable the creation of those bindings,
because otherwise lazy-loading a package could stomp on user-defined binding.
(The only other solution would be to add a bunch of `with-eval-after-load`s to
your init file to restore your personal bindings, which is not very
user-friendly, IMHO.)

One possible way to avoid this problem could be to basically do what Magit does:
ensure that packages install their global key bindings only if they're not
already bound. Emacs could provide a macro to do this, let's say
`maybe-global-set-key`, which package authors would then be encouraged to use.
If certain keymaps were reserved for external packages, as per your proposal,
this method would also avoid the problem that `C-x g` raises now. By using
`maybe-global-set-key`, a package author would know they won't be stomping on a
user's preferred key bindings and at the same time they'd have the guarantee
that Emacs would never override their bindings, ever.

It wouldn't solve another problem, however, which is that the key bindings a
user finds in their Emacs will depend on the order in which packages are loaded.
You say that the likelihood of two external packages using conflicting key
bindings is low, but I believe this is mainly due to the fact that most external
packages follow the unspoken rule that they shouldn't create global bindings.
But if Emacs reserves certain keymaps for external packages, it's likely many
packages will start binding these keys, raising the potential for conflicts. And
when that happens, the order in which packages are loaded matters.

The only way to avoid that would be for each package to provide an option to
disable the creation of its global bindings. But the system you'd end up with is
complex and confusing for the user, I think. For each package you install, you'd
have to find out whether its key bindings override those of another package and
then make sure to load them in the correct order or set the option not to create
the bindings.

It's more straight-forward, I think, if you can just add a `require` or
`use-package` statement to your init file and add the key bindings you want. No
need to think about the place where you load the package in your init file or
whether you want to lazy-load a package.

Package authors would then simply include the code to create their proposed
key bindings in their installation instructions and every user would have the
opportunity to decide whether they want to put that code in their init file or
not. There would be no potential side effect to consider and all non-standard key
bindings would be located in one place: the user's init file.


-- 
Joost Kremers
Life has its moments