Re: defcustom: changing from defvar - order of execution

[Per Abrahamsen]

"Drew Adams" <drew.adams@oracle.com> writes:

>   (defcustom align-load-hook nil
>     "*Hook that gets run after the aligner has been loaded."
>     :type 'hook
>     :group 'align)
>
>   (run-hooks 'align-load-hook)

Load hooks are rather special, and shouldn't be declared with
defcustom.  Anyone using a load hook should be comfortable with Emacs
Lisp.

> Here's another example:
>
>   (defcustom apropos-symbol-face 'bold
>     "*Face for symbol name in Apropos output, or nil for none."
>     :group 'apropos
>     :type 'face)
>
>   (define-button-type 'apropos-symbol
>     'face apropos-symbol-face
>     'help-echo "mouse-2, RET: Display more help on this symbol"
>     'follow-link t
>     'action #'apropos-symbol-button-display-help
>     'skip t)

Problematic in any case, since changing apropos-symbol-face from
customize will have no immidiate effect.  It would be better to have
apropos-symbol-face being an actual face, inheriting from bold.  But
because face inheritance wasn't in Emacs 19.0, Emacs is very
incosistent about when to use faces, and when to use variables
containing faces.  Also in new code, since bad habbits don't die
easily. 

>   (defcustom mouse-avoidance-mode nil...)
>   (if mouse-avoidance-mode
>       (mouse-avoidance-mode mouse-avoidance-mode))

Is there a :set in the defcustom?  Global minor mode variables should
have one, so changing the variable from customize will turn the minor
mode on or off.  This will also solve the initialization order problem
(with the risk of doing some unnecessary work).

> Here's another example:
>
>   (defcustom calculator-use-menu t ...)
>   (or calculator-mode-map
>       ...
>       (if (and calculator-use-menu ...

calculator-use-menu should be a global minor mode, see above.

> These examples are taken from just the first few standard Elisp libraries,
> sorted alphabetically. I could go on, but you get the idea.

As you see, the answer depends on the example.  But a common answer is
that if you need to depend on a user variable in the initialization,
the user variable should have a :set that undo the effect if the user
change it.

> How is the user's customization (via Customize) taken into account in such
> cases, if the custom-set-variables form is inserted at the _end_ of his
> .emacs or custom-file? It looks to me like the _library_ (default) values of
> such variables, not the user's customized values, will be used in the
> library.

The location in the .emacs file is just exposing the problem to more,
in all cases the problem would show up if the library was loaded from
the site initialization file, or even dumped with Emacs.