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.