RE: defcustom: changing from defvar - order of execution

["Drew Adams" <drew.adams@oracle.com>]

Per Abrahamsen said:

    Load hooks ... shouldn't be declared with defcustom.
    ...
    Emacs is very incosistent about when to use faces [vs variables]
    ...
    calculator-use-menu should be a global minor mode

OK, I guess the standard libraries need a bit of cleanup in this regard.
These samples came from just the first few files. I know that Luc Teirlinck
already pointed out in emacs-devel that defcustoms for hooks were
problematic, and that there will perhaps be an effort to clean up such stuff
after release 23.

    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.

Thanks; that guideline makes things a bit clearer. However, such use of :set
seems complex to me (perhaps just because I'm not yet used to it). I need to
look more at how it's used.

    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

Yes. That's part of what I meant.

To come back to my original example, I guess the thing to do is this:

 - Ensure that libraries make no use of user options at the top level. IOW,
always encapsulate such use inside defun's (e.g. `foo-fn').

 - Tell the user (e.g. in library comments) that to use `foo-fn' at startup
it must be called *after* `custom-set-variables', not before:

     (load-library "foo")
     ...
     (custom-set-variables '(foovar t)...)
     ...
     (foo-fn)

-----------------------

The rest of this email is about the first of these guidelines, and it might
be somewhat off-topic for help-gnu-emacs.

I noticed that RMS said this recently in emacs-devel:

    Just loading appt.el probably should not activate the feature.
    In the 90s it was not unusual for packages to work that way,
    but when Custom was added it became common for a package to be
    loaded simply because someone wanted to customize a variable.
    So our convention, since then, is that just loading a package
    shouldn't really change anything.

Not only was this common in standard libraries before this century, but it
is still common for personal "libraries" - that is, .emacs and its
extensions. It is normal for the latter, IMO, as long as they don't contain
defcustom's.

I said this in emacs-devel on Feb 8:

    I hope and expect that (beyond the bugs) few
    libraries will ever need to change user options, at least
    not by simply being loaded. Most will a) define standard
    values for options or b) provide commands to set options
    or c) behave themselves properly by modifying only
    non-user-option variables.

    I should make a distinction here - there are libraries
    and libraries. There are libraries that are intended for
    use by multiple users, and there are libraries that are
    essentially custom files or personal extensions thereof.
    Multi-user libraries are the ones that should not step on
    user options. Personal libraries are made to set user options.

    Some libraries start out life as a personal library and
    end up being shared to some extent by others. In
    some cases, user-option settings in a library shared this
    way are not bothersome - if the person using the library has
    the same environment and wants to do the same thing, for
    instance. This is essentially just cutting and pasting code.

    In general, however, a library destined for multiple users
    should not contain user-option settings - that is bad form.

That is, some "libraries" are, in effect, .emacs settings (setq...) and
startup code that have been relegated to one or more separate files loaded
at startup. Lots of users do that, to help them organize their settings. (A
common use is to deal with different settings for different platforms.)

It might make sense to have a standard, recognizable (textual) way to
distinguish these two types of emacs-lisp files ("libraries"), so users (and
tools) could more easily apply the different kinds of guidelines to them.

A first step, I think, is recognizing the different kinds of file and
establishing clear guidelines for each. In particular, their treatment wrt
customize is likely to be quite different. For example:

 1) std library: defcustom, defun, etc. only - no top-level setq or function
calls etc.
 2) personal startup library: top-level function calls, setq etc. Executed
after custom-set-variables, usually.

Coming up with such guidelines would also help people migrate a personal
library to become a clean multi-user library. A complete set of such
guidelines would include heuristics, such as the :set rule Per mentioned,
for dealing with customize.

It is, I guess, thanks to the introduction of customize that the standard
libraries are being forced to become cleaner wrt initializing and activating
things. And customize considerations are driving the separation in form
between standard libraries and personal startup libraries. Things that were
commonly done in both a few years ago are now appropriate only for one or
the other.