Default hook state and the test suite

[Stephen J. Turnbull]

Andrew Bennetts writes:

 > Part of me wonders if always-installed hooks are a bit of a code smell,
 > though...

They're a necessary evil with mutually recursive modules, when those
modules get sufficiently complex.  For example, in the XEmacs
architecture, internal modules have a potentially very complex set of
functions that constitute their initialization: init_MODULE_very_early,
init_MODULE_early, init_MODULE_once_very_early, reinit_MODULE_early,
syms_of_MODULE, MODULE_create_objects, ... and we haven't even gotten
to the init_MODULE family yet.  These are conventional names for
functions that should be called at specific points in the
initialization process, so you can see that we have evolved a very
complex system of checkpoints (~= dependencies) in that process.

Of course those aren't "hooks" in the sense of user-configurable (in
fact as you probably guessed they're hard-coded in C), and in practice
XEmacs (and GNU Emacs, whose architecture is a bit different) has a
policy against always-installed hooks on user-configurable hook
variables.  Sometimes this is quite inconvenient, though, because new
modules often want to install initializations with complex
interdependencies with the existing core, and there are a *lot* more
user hooks than there are internal ones.  So often there is a user
hook but not a place for core functionality to register a hook.  And
hard-coding those calls to initializations violates modularity
slightly.

N.B. I'm not necessarily recommending either the XEmacs architecture
or an anti-always-installed-hook policy, just commenting that in our
experience is that this is a hard problem without a generic solution.