RE: [External] : Configuration files vs customization

[Dr Rainer Woitok]

Drew,

On Saturday, 2023-01-21 17:44:12 +0000, you wrote:

> > ...
> >    ;; Your init file should contain only one such instance.
> >    ;; If there is more than one, they won't work right.
> 
> More precisely, they _might not_ work right.  And "work
> right" is vague.  What that really tries to say, IMO,
> is that unless you know what you're doing, it's a good
> idea not to use multiple `custom-set-variables' sexps
> in the same file.

Am I correct in assuming  that this has to do  with "customize" just re-
placing the first call  to "custom-set-variables"  with the new settings
when saving?

> ...
> > function "custom-set-variables" writes into my "custom.el" file,
> 
> No, it doesn't write anything anywhere.  It only _sets_
> the variables you pass it to the values you provide.
> They're set for the current Emacs session ... until you
> set them again or reset them.

You're right:  this comment is embedded by "customize" (or some function
it calls) into the CALL  to function "custom-set-variables"  in my "cus-
tom.el" file.

> ...
> The point about using Customize (the UI), or the custom
> and customize functions - _instead of setq_ - is that
> setq doesn't know about any :init or :set additional
> processing that's required/intended/expected when you
> initialize or change the value of a user option.

That's what I meant  when I said that  "you may customize this variable"
in the output of "C-h v VAR" at least in some cases means "you MUST cus-
tomize this variable".   I think it would help a lot of people  (and not
only Emacs novice users),  if function "describe-variable" could inspect
the variable in question a bit more closely and then chose the appropri-
ate wording.

And while we are at it: the Gnus documentation, both locally in the Info
pages and on the internet at

   https://www.gnu.org/software/emacs/manual/html_node/gnus/

only talks about using  "setq" for defining  configuration variables and
never ever about customizing them,  thus potentially discouraging people
from using Gnus at all  (actually, after I failed to get my old Vm runn-
ing,  I decided to  abandon this  unmaintained package  and use Gnus in-
stead.  But it was only after I failed configuring even Gnus and getting
it running,  that I had the -- successful -- idea of customizing all and
sundry, which then also succeeded for Vm, phew :-)

So,  whoever is in charge of the documentation section of an Elisp pack-
age should check  and where necessary  update its configuration section.
Apparently,  some packages' documentation sections were written long ago
and before function "customize" was introduced.

> ...
> > So being forced to put more or less  all application 
> > specific configuration into one big "custom.el" file
> 
> You're not.
> 
> > which on top of all does only accept constants as values
> 
> Untrue.  The `custom*' functions evaluate their args,
> so you can pass them any Elisp code you like, which
> is evaluated.  The `custom-set-variables' form that's
> automatically written to your `custom-file' or init
> file uses quoted lists (constants) as the args.  But
> that doesn't mean that `custom-set-variables' expects
> constant values as args.

Yes,  I can use argument "NOW" to have "custom-set-variables" evaluate a
value.   But if I ever have "customize" save customization changes to my
"custom.el" file,  it writes back the evaluated value for this variable,
even if it wasn't changed.  That's not really what I want, because after
saving the new customization this way,  file "custom.el"  is only usable
on this host, architecture,  operating system, user,  you-name-it, since
whatever "getenv" returned in the moment  of saving the customization is
now hardwired into my "custom.el".

> ...
> You can have any number of separate config files,
> which you load from your init file.

Configuration files: yes.  But customization files?  Even if I set vari-
able "custom-file"  before running  "M-x customize" --  after saving the
changes,  the file "custom-file" is pointing to would contain _ALL_ cur-
rently loaded customization  not only that from the single customization
file I wanted to update!

Sincerely,
  Rainer