Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip K.]

Gregory Heytings <gregory@heytings.org> writes:

>>> When such packages need to bind a command to a key, they can (1)
>>> either suggest users to bind it to a key reserved for users (for
>>> example, org-mode suggests to globally bind "C-c c" to
>>> org-capture), or (2) bind it to a key currently unused by Emacs
>>> (for example, Magit binds "C-x g" to magit-status in buffers
>>> visiting a file in a Git repository).
>>>
>>> Neither of these solutions are optimal: (1) requires an explicit
>>> configuration by the user, something which might confuse newcomers,
>>> and which other users might not want to do because they already use
>>> the keys reserved for users for other purposes, and (2) might
>>> conflict with the evolution of Emacs when one or more commands are
>>> bound to a yet unused key.
>>
>> I don't think this is a good idea, because situation (1) is good,
>> actually.  Configuring a package, that provides a command as it's 
>> interface, should be done by binding it to a key reserved for
>> users. Just like how configuring a minor mode is done by adding it
>> to a hook or a major mode by adding it to auto-mode-alist.
>>
>
> Situation (1) might be good in theory, it was probably good twenty
> years ago, but at least nowadays it is, in practice, not good.  What
> most users do is that they install third-party packages through their
> distro package manager, or through Elpa or Melpa, and they just expect
> / would like it to work.  That's what would happen when you install
> extension packages in most (if not all) other software (editors,
> browsers, ...): you don't have to manually fiddle with configuration
> files to make them work.

If I install ffmpeg via apt on a Debian system, I expect it to work, in
the sense that I can invoke the command from the terminal whenever I
want to use it.  I don't think the analogy works for browsers, since
add-ons are usually filters or added to right-click menus.  I don't know
enough about other extensible editors, but if they do too-smart-for-me
guessing, that's probably why I don't use them.

What might be interesting would be something like the gnu-elpa
package[0], or something that goes in the other direction, where a
package can recommend a keybinding, hook, etc. and "automatically"
configure itself if the user agrees.

The problem I see is that key-bindings are usually user configuration,
and e.g. Magit *works* without them. I can do M-x magit-status, right
after installing it. No extra configuration necessary. But if I want to
have it easier, it's easy to add.

> It's probably not without reasons that packages such as Magit bind
> keys globally.

AFAIK this was discussed in [1], but I don't get it, and I think it was
a bad decision.

>>
>> If you ask me, packages should try to minimize change the
>> environment when they are installed, as I've argued in [0].  In
>> other words, package-install shouldn't have any side-effects, beyond
>> installing a package.
>>
>
> That's not what most users expect.  When you install a package, you
> just expect it to work.  If they install a package to edit, say,
> Python code, they expect it will be used the next time they open a .py
> file.  If they install Magit, they expect it will work when they open
> a file in a git repository.  If they install Ivy, they expect it will
> take over C-x C-f, C-x b, and so forth.

I think Ivy is a good example where this should *not* be the case,
because it changes the user-interface that can be confusing. Major modes
might be ok, but the edge-cases is where it's critical: Let's say there
were two third-party packages for perl and prolog. It's common for both
to use the ".pl" extension, but which should get it. If I have been
using perl for a while, and I install prolog, should the new package
just "steal" the extension? Same goes for key-bindings. This should not
be done automatically, and reserving a name-space to solve this issue is
the wrong approach.

But setting that aside, I think that this expectation is just "wrong".
Packaging doesn't do configuration, and we shouldn't encourage this
misunderstanding. What works for some, breaks stuff for other people,
and that should be respected.

[0] http://elpa.gnu.org/packages/gnu-elpa.html
[1] https://github.com/magit/magit/pull/4237

-- 
        Philip K.

signature.asc
Description: PGP signature