RE: A fundamental problem with defcustoms that are lists

[Drew Adams]

> If you have a defcustom which uses variable length lists
>   (defcustom my-option
>     :type '(repeat ...))
> 
> then you may want the default values from the list but also 
> add some of your own.
> 
> If you customize such an option and the default values are changed you
> will not notice because when your setting is used Emacs never sees the
> changes in default.
> 
> This mean that any enhancements or bug corrections to the default will
> never be used.
> 
> Wouldn't it be worthwhile to give some way to add entries at the
> begining or end of the list but add those to the default value instead
> of just replacing the default value?

A clear recipe would have helped, but I think I know what you mean.

I'd say no. 

The default value of a list option is typically not just a starting point to add
to but is a default value to replace. What you raise is the difference between a
default value that is a list and a list that includes a minimum set of values by
default, that is, a list of default values.

In the latter case, a library can do something like this:

(defvar foo-defaults '(a b c) "List of default values")
(defcustom foo-extras () "Your added values"
  :type '(repeat ...))
(setq foo (append foo-defaults foo-extras))

You would then customize only `foo-extras' in your scenario, and any update to
`foo-defaults' would be accommodated automatically. This is the way to express
that a user's changes are limited to additions to a list of default values, not
replacement of that list (as a single default value).

And `foo-defaults' could itself be a defcustom if we want to let users define
the list of default values for `foo'. The difference between the (purposes/uses
of the) two options should be made clear to users.

In short, if you don't want to lose something, start with nil. "When you ain't
got nothin, you got nothin to lose." ;-)

I think what you're asking for is that all list options `foo' automatically
provide a way to customize only the "extras" part. I think such a possibility
should be explicitly provided by the library itself, and only when appropriate.
It is only the library that really knows what "default" means and whether it
makes sense for users to typically include the defaults and only add to them.

The problem you raise is not fundamentally different if a non-list defcustom is
used. Any existing user customizations will not take into account a change in
the default value for a new version of the library. And that default-value
change might well mean that a user would want to change (or remove) an existing
customized value.

I think there is no magic solution to this potential gotcha - it's what default
values are all about. Library changes that are likely to make users want to
rethink their customizations are similar to incompatible changes. Even when not
truly incompatible, users should be made aware of them. This can be pointed out
in the library's doc or even by a runtime or customize-time message. Only the
particular library can know whether a particular option or particular code
change needs to be treated this way.