Re: Making `eglot-server-programs' a custom variable?

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: jporterbugs@gmail.com,  arash@gnu.org,  emacs-devel@gnu.org,
>>   joaotavora@gmail.com
>> Date: Sat, 12 Nov 2022 09:40:23 +0000
>> 
>> >> > The way to do this is to have a basic value as a defvar, and store the
>> >> > corrections to that in a defcustom.
>> >> 
>> >> But in that case you need to load the library to get the default value,
>> >
>> > I don't see why.  And even if it's so, why is it a problem to load the
>> > library?
>> 
>> (I'm not just talking about Eglot right now)  If the default value is
>> defined in an non-autoloaded variable, you have to load the library to
>> access the value -- otherwise it simply wasn't loaded.
>> 
>> The "issue" here is just that loading everything you want to modify
>> during initialisation can get slow.
>
> Whether or not it is necessary to load the library depends on how the
> :set function of the defcustom is implemented.  I can see several ways
> of implementing it that won't require loading the library right away,
> and I'm sure you can see those ways as well.

Actually no, I am not sure I do.

>> >> in which case you might as well store the default value in the
>> >> defcustom.
>> >
>> > But you already explained why storing in a defcustom doesn't solve the
>> > problem?  So why are you suggesting to do that anyway?
>> 
>> ^^ I am not sure I explained that?
>
> You said:
>
>> >   M-x customize-variable RET image-load-path RET
>> 
>> My issue here is that while you can modify the list, when saved you will
>> store the entire modified list, and no the modifications you made on the
>> base variable.
>
> To me, this says that storing the value in a defcustom hits that
> "issue" to which you were alluding, and for which I proposed a
> solution of having the defcustom be an add-on to the baseline value.

I see.  The issue is that if I just set the user option directly, say
even before loading the library I overwrite the default value.  But if I
load the library, I will have access to the default value before
modifying it and setting the user option.

>> If you have to load the library to
>> get the default, writing
>> 
>>     (setopt foo (cons 'bar foo))
>> 
>> or
>> 
>>     (setopt foo (cons 'bar foo-default))
>> 
>> doesn't make much of a difference to me.
>
> Sorry, I don't see the relevance of setopt to what I was trying to
> suggest.

There are two fundamental ways to work with user options, right?  Using
the Customise interface and programmatically, e.g. using `setopt'.  The
discussion began with finding a programmatic way of modifying the
default value of a user option that contains some repetitive type
(repeat, alist, plist), which we were calling `add-to-

>> >> Also, I don't think this helps people who use the Customize
>> >> interface?
>> >
>> > Why doesn't it help?
>> 
>> Maybe I have missed something, if a user option has a `repeat' or
>> `alist' type, you can't just say "append this and that value to the end
>> of some other value".  All you get to modify is the entire list, and all
>> you get to store is the entire list.
>
> That's a job for the :set function of the defcustom.

I am not sure I know what you are thinking of, but wouldn't this mean
all user options that have already been marked as having a `repeat' or
`alist' type, that these would now require an additional :set function?