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?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4