I'm still a bit confused though. For example, mh-show-mode-hook is defined implicitly by the definition of mh-show-mode in mh-utils.el which requires mh-customize.el which contains the defcustom of mh-show-mode-hook. Shouldn't that defcustom have won against the defvar in the mh-show-mode?
I should look at the details to figure that out. But do not forget that add-hook also will bind an undefined hook, just as defvar does. Custom and hooks quite simply do not work very well together. Per designed Custom under the assumption that there are two disjoint classes of variables: internal variables for use by programs and Custom variables for user customization which programs should never touch. Emacs does not satisfy that assumption and this creates problems. These problems are the worst for hooks, which should be manipulated with add-hook and remove-hook, not with setq-default, as Custom does. I described several nasty problems related to Custom and hooks earlier. This is a yet another one. We are planning for a fix, but decided it was too involved to do before the release. (add-hook 'foo-hook 'essential-function) custom-set-variables: The custom-set-variables undoes the add-hook. This is a problem I described earlier. It could create problems if a user upgrades to an Emacs version in which essential-function is new and essential. It is a constant potential pitfall for CVS users. But now: custom-set-variables (add-hook 'foo-hook 'essential-function) defcustom: Now the add-hook means that the user's customization is ignored. This is yet another problem related to Custom and hooks. custom-set-variables defcustom (add-hook 'foo-hook 'essential-function) will work as intended, but I see no way to always guarantee this order. I'd still be curious to hear the opinions on whether one should use the ;;;###autoload cookie on the defcustoms or not. It could solve the newly pointed out problem with Custom and hooks, but would not solve the other ones, like, for instance, the first one I pointed out above (there are others). Some people who do not have a lot of memory available might not like it. Sincerely, Luc. _______________________________________________ Emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
