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?
> 
> > The default value of a list option is typically not just a 
> > starting point to add to but is a default value to replace.
> 
> Why do you think so?

That's what a default value is: something you can replace. The question is
whether your non-nil value serves as the default value of a list (hence, can be
replaced) or is a list of default values to serve as the minimal starting point
of some other list.

Perhaps two different informal senses of the word "default value" are leading to
confusion. If a list always starts out with elements (1 2 3) regardless of your
customizations, you might want to call that starting point its "default value",
but that is not the sense of "default value" that is implemented by defvar or
defcustom. They use "default value" in the sense of the value that is used if
you don't replace it with something else.

Another way to say it is that you want to customize the list in a way that only
adds to what was there, not replace it. That is a different customization
mechanism. There are ways for a given library to let you do that, as I pointed
out.

> There are certainly situation when this is the case, but I can without
> doubt point to other where instead the default value is 
> useful and it is natural to complement it, not replace it.

Those sound like cases where a list of default values is called for, not a
default value that is a list. We can only judge that on a case-by-case basis -
be specific.

The question is what you (a library) want/expect users to replace: the whole
list  or just part of it. If you want some part of it to always be there, then
include that part automatically, outside of the user's customization. In that
case, start the user-replaceable part off with a default value of nil.

But I'm repeating myself.

> > 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))
> 
> I can see your idea (but it should not be handled the way you propose
> above, use :set instead).

Fine. The exact mechanism used is not important here.

I was trying to point out the difference between a list of default values and a
list that serves as a default value, and that it is the library and its use of
the list that decides which it needs (possibly both).

> But that would not give the same flexibility as what I propose.

Be specific.

> Here is my proposal a bit more concretely expressed:
> 
> - In the values stored for a list (ie type 'repeat) for a defcustom
> allow a value 'custom-insert-default to insert the default 
> value for the 'repeat list.

How is that better than having a separate variable (or function) that provides
the list of default values, and having the code splice that in where needed? Is
it that you are trying to give the user greater control over where the
default-values list is spliced in?

I really don't see a useful use case for this. Why don't you start by explaining
your concrete use case or a problematic situation? Either you will convince
people that something "fundamental" is in fact missing, or someone will show you
that you can already do what you want.

> Is that clear? Of course the UI have to provide functionality 
> for this too.

I don't see a need for such a thing, so far. Maybe someone else does. AFAICT,
all that is needed is a single mechanism to provide for a default value. It's up
to library developers to use that appropriately.

But I don't want to discourage you. I was just trying to help, thinking that you
were perhaps a bit confused. Please detail your use case and your proposed
solution. I'll keep quiet and let others help.