Emacs package customization and autoloads

Question

I am adding Customize support for a package that provides a couple of global mode-independent commands. As I do not want to load the package unless the user explicitly invokes the commands through keybindings yet I want to allow customization right after the user installs the package, I tried to use code like:

;;;###autoload
(defcustom foo-bar nil 
 "bar setting for for"
 :type boolean)

;;;###autoload
(defun foo-command-1 () ...)

With that after I install the package I can invoke foo-command-1 . I can also use customize-variable to set and save foo-bar . However, when I start Emacs again, the value of foo-bar is reset to default and Emacs complains that the value is changed outside customize.

AFAICS the reason for this is that the code that Emacs puts into the autoloads file for defcustom assumes that it will run before Emacs calls custom-set-variables in the init.el . However, this is not the case with a package which autoloads are run after the init file.

Is this a known problem? To workaround I replaced the above with something like:

;;;###autoload
(unless (fboundp 'foo-command-1)
 (defcustom foo-bar nil 
  "bar setting for for"
  :type boolean))

;;;###autoload
(defun foo-command-1 () ...)

That copies the whole defcustom definition into the autoloads and prevents running it the second time when the package is loaded for real. This works and saved options are properly restored. Still I am puzzled why ###autoload for defcustom does not do the right thing on its own.

Answer 1

Yes, what you did is a reasonable way to accomplish what you want. If you want to autoload a defcustom and you care about when it will be evaluated relative to other code, then you need to control that timing in some way. The way you chose is reasonable.

A user's init file can load custom-file at any point the user chooses. And if no custom-file is used it is still not sure at what point the part of the init-file code that is managed by Customize will be evaluated with respect to other parts that might depend on values that it sets.

Answer 2

As a general rule, you don't want to autoload variables.

Yes, it's a known problem, and there's no really good solution to it (each solution I could come up with had its own set of bugs/misbehaviors), which is why all I can say is "don't autoload variables, please".

Even in the case where it happens to do what you want, it's undesirable in my experience. It just has too many quirks and corner cases.