Here's what happens, for those of you who write and hack on packages:
Emacs tries balancing the customization abilities and expressiveness of its extension language. This is why
defvar (and by extension,
defcustom) behaves in a somewhat surprising way. Consider this:
(defvar foo 42) ; define foo with 42 as value
(setq foo 13) ; set foo to 13
Nothing special here. A variable is declared and initialized, then it's set to a different value. What happens if we do it the other way around?
(setq foo 13) ; set foo to 13, defining it in the process
(defvar foo 42) ; marks variable as special, but doesn't change value
You might have expected that the
defvar overrides the previous assignment, but Emacs treats this case deliberately different. The idea is that if the user has set a variable before it has been declared and initialized, whatever the user set it to shall stay its value. Therefore the
defvar merely marks the variable as special, but doesn't change its value. This is usually the right thing to do with customizables.
Now, imagine we're not working with
foo, but a hook variable and the contents aren't a number, but a list of symbols. In this case we really want to start out with a meaningful value (as opposed to it being ignored if the variable is set before that) and allow the user (or any code of our own) to add functions. For this case there's the following idiom:
(defvar some-hook nil)
(add-hook 'some-hook 'foo)
(add-hook 'some-hook 'bar)
Suppose the user did
(add-hook 'some-hook 'baz). No matter whether this has been evaluated before or after the above code, you'd always have the functions
baz in the hook, only the ordering would be different. This is the recommended pattern for hooks and other customizables where the initial contents matter.