Re: A fundamental problem with defcustoms that are lists

[Lennart Borgman (gmail)]

Drew Adams wrote:
> 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.

I clearly want both possibilities. (And you are again saying that they
should be different cases. I said before I do not agree with that.)

> 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).

Yes, both. That is the normal case in my opinion.

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

It is about giving the both the possibility to replace the default value
and add things to it.

I took lists as an example. There might be other cases too, but this is
the most important case I believe.

>> 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?

Yes. Plus that it gives the user the freedom to replace all values.

> 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.

I can give that later if it is needed.