RE: [External] : Configuration files vs customization

[Drew Adams]

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

To my understanding, yes.

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

Maybe you mean to say that it means that IF you want
to change the value THEN you must use Customize.

That's closer, yes.  But it's not a must.  Not a must
that you use the Customize UI, since everything it
offers (other than interactive editing) is available
also with custom* functions.

And not a must because,\ in fact there are many user
options for which there's no associated :set or :init
etc. function, and for those you can reliably change
the value with setq.  However, changing the value
doesn't save the value persistently.  If the setq is
in a file that you always load then yes, the effect
is persistent.

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

`M-x report-emacs-bug', to file an enhancement request.

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

`M-x report-emacs-bug'

But changes to the manual serve for both the manual
in Info and the manual online in HTML.  The change
only needs to be made once.  (Of course, it's only
for the latest released version of Emacs.)

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

`M-x report-emacs-bug', but be specific in your
enhancement request about which sections in
which manuals. 

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

Yes.  Customize itself isn't designed to take any
sort of conditional reasoning/code a user might
have in mind into account.  For that users have
Elisp. ;-)

A given user option could have a :set function
that takes platform, release, or whatever into
account and DTRT.  But that's up to the person
who designs/adds that option to do.  Customize
can't guess what any such relevant conditional
handling might be.

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

My point was that you're not limited to a single
file, `custom-file'.  You can code whatever
option & face behaviors you want, in as many of
your own files as you like, using any conditional
behavior you like/need.

The point really is that if you want to customize
a user option, you should take into account any
:set and :init etc. functions its defcustom uses.
There are custom* functions that do this for you.
But you're not obliged to use them.  You can code
the same or other behavior you like, to handle
:set, :init, etc.