[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: Making `eglot-server-programs' a custom variable?
Date: Sat, 12 Nov 2022 12:02:55 +0200

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

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

> 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]