Standard Interface for Enabling Extensions

Owner: ???

Effort: ???

Dependencies: ???

Abstract: Apparently, if you know the name of a package (for example, fusion), you can load it using the require function, but there's no standard way to turn it on or turn it off. The only way to figure out how to do that is to go read the source file, where hopefully the comments at the start tell you the appropriate magic incantations that you need to run in order to turn the extension on or off. There really needs to be standard functions, such as enable-extension and disable-extension, to do this sort of thing. It seems like a glaring omission that this isn't currently present, and it's really surprising to me that nobody has remarked on this.

The easy part of this is defining the interface, and I think it should be done as soon as possible. When the package is loaded, it simply calls some standard function in the package system, and passes it the names of enable and disable functions, or perhaps just one function that takes an argument specifying whether to enable or disable. In any case, this data is kept in a table which is used by the enable-extension and disable-extension function. There should also be functions such as extension-enabled-p and enabled-extension-list, and so on with obvious semantics. The hard part is actually getting packages to obey this standard interface, but this is mitigated by the fact that the changes needed to support this interface are so simple.

I have been conceiving of these enabling and disabling functions as turning the feature on or off globally. It's probably also useful to have a standard interface returning a extension on or off in just the particular buffer. Perhaps then the appropriate interface would involve registering a single function that takes an argument that specifies various things, such as turn off globally, turn on globally, turn on or off in the current buffer, etc.

Part of this interface should specify the correct way to define global key bindings. The correct rule for this, of course, is that the key bindings should not happen when the package is loaded, which is often how things are currently done, but only when the extension is actually enabled. The key bindings should go away when the extension is disabled. I think that in order to support this properly, we should expand the keymap interface slightly, so that in addition to other properties associated with each key binding is a list of shadow bindings. Then there should be a function called define-key-shadowing, which is just like define-key but which also remembers the previous key binding in a shadow list. Then there can be another function, something like undefine-key, which restores the binding to the most recently added item on the shadow list. There are already hash tables associated with each key binding, and it should be easy to stuff additional values, such as a shadow list, into the hash table. Probably there should also be functions called global-set-key-shadowing and global-unset-key-shadowing with obvious semantics.

Once this interface is defined, it should be easy to expand the custom package so it knows about this interface. Then it will be possible to put all sorts of extensions on the options menu so that they could be turned off and turned on very easily, and then when you save the options out to a file, the design settings for whether these extensions are enabled or not are saved out with it. A whole lot of custom junk that's been added to a lot of different packages could be removed. After doing this, we might want to think of a way to classify extensions according to how likely we think the user will want to use them. This way we can avoid the problem of having a list of 100 extensions and the user not being able to figure out which ones might be useful. Perhaps the most useful extensions would appear immediately on the extensions menu, and the less useful ones would appear in a submenu of that, and another submenu might contain even less useful extensions. Of course the package authors might not be too happy with this, but the users probably will be. I think this at least deserves a thought, although it's possible you might simply want to maintain a list on the web site of extensions and a judgment on first of all, how commonly a user might want this extension, and second of all, how well written and bug-free the package is. Both of these sorts of judgments could be obtained by doing user surveys if need be.

Ben Wing

Conform with <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Automatically validated by PSGML