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

[Philip K.]

Gregory Heytings <gregory@heytings.org> writes:

>> A theme doesn't activate when it is installed or loaded, but when it
>> is activated. In the same way, I argue, a command shouldn't bind
>> itself until it is bound. Note that I don't insist that this has to
>> be done by editing your init.el (as shown in the patch from a few
>> messages before). I just think that loading a feature/package should
>> attempt to just load the package, without changing the UI/UX of the
>> system.
>
> I fear you're splitting hairs here: the distinction between "install",
> "load" and "activate" is not important in this discussion, with the 
> current state of affairs neither installing nor loading nor activating
> the package can automatically create a global key binding.  The
> proposal is an attempt to make that possible.

Well none of these should so it, with the possible exception of
activating, that I'll mention again below. But I still think that the
distinction is important, if only because it is real. I recently
realized there would be another problem with this approach, as you also
mentioned that global modes should activate themselves on installation,
specifically naming Ivy, the completing-read framework. But what if
someone decides to install Helm? Will these two modes now interfere,
possibly breaking everything, or is it Helm's responsibility to
deactivate Ivy. If so, does every completion framework have to know
about every other one?

I think this shows that adding code like

        ;;;###autoload
        (ivy-mode t)

is bad style, even if a beginner manages to deactivate Ivy or Helm, the
same issue would arise every time Emacs is restarted, which creates the
feeling that the entire system is fragile -- and it is, because
fundamental operations like "install", "load" and "activate" are kept
apart.

As for key-bindings, if we assume that like Magit, any package can just
autoload a global-set-key, we are just inviting bug-reports complaining
about "Key sequence [something] starts with non-prefix key [something
else]", or key-bindings being over-ridden or chaining from session to
session.

Situations like these, tell me that adding user-customization directly
as autoloaded code is harmful and would at least require a level of
abstraction in-between.

>>> Do you also think it's a mistake and unfriendly if a package
>>> installs a menu item?  If not, what makes keybindings fundamentally
>>> different from menu items?
>>
>> Do you mean a menu-bar-mode item? Yes, loading a package still
>> shouldn't change anything, activating a mode should add the menu
>> item
>
> Okay, so if you agree that activating a mode can automatically add a
> menu bar item, why don't you agree that it should be possible to
> automatically add a global key binding while activating a mode?
> Again, what makes key bindings fundamentally different from menu bar
> items?

Activating a mode and deactivating a mode are "inverse" operations. This
is important, because it makes mode activation reversible, and lets the
user feel like he or she is in control. Therefore, if a
global-minor-mode, which I assume we are talking about, binds a global
key, it must not only un-bind it when it is done, but restore the
previous binding, if there was one. The tricky part is now if a second
global-minor-mode comes along, and wants to rebind the same key, also
saves the same command and then installs it's command: Now deactivating
the first mode would either have to check if the key it has bound is
still bound, and only undo it's operation if that is the case, or it
just re-binds the old key, overriding the binding of the second minor
mode. Neither of these are good approaches, and they cannot be resolved
without both global-minor-modes either knowing details about one-another
or having a protocol they follow to save keys.

The difference to menu items is that collisions like these are not
possible, you just add and remove an item from a list, without having to
fear collision (with the possible exception of having two items have the
same name, but that's an issue on a different level).

This demonstrates why a mode binding a key to the global-map is
difficult, and why it should instead use it's own map, that is installed
when said mode is activated.

-- 
        Philip K.

signature.asc
Description: PGP signature