sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
As long as defcustom'ing doesn't zap the initial value (I
don't recall
the customize semantics exactly), it's absolutely fine with me. The
startup code is just that---code to be run at startup.
It doesn't, but:
- Custom will tell the user that the variable has changed outside
customize when he tries to customize it. This may confuse the
user.
- When the user saves the variable, it will overwrite the value from
the startup code. Not add to it. This means he will be bound to a
specific location for the XEmacs distribution.
In general, my advice is to split such user options in two. One for
the standard (computed or large default) part, and one for the user
specified part.
It would be possible to extent custom so it could append or prepend to
lists, instead of overwriting them. But the price would be a
significant increase in complexity of the package. Now, how many here
thinks they understand custom with the current level of comlexity? I
find it hard, and I wrote it.
Even without custom, I think it is a good thing if users in general
can make customizations with `setq' alone, and not have to learn (and
understand) advanced concepts (to a non programmer) like `add-to-list'
or `push'. So user options should in general be overwritable.