Gregory Heytings 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.