RE: [External] : Configuration files vs customization

[Drew Adams]

> Personally, I hate this clicky-clicky customization interface because it
> doesn't evaluate the values, even though function "custom-set-variables"
> provides an option to do so.  Thus you can't  use things like  '(getenv
> "HOME")', '(getenv "HOST")' or '(cond ...)'.
>
> The lack of this flexibility makes configuration rather tricky.
> And according to the comment
>    ;; 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.

Even better advice is to let Customize use `custom-file',
and use some other file(s) (could be your init file, but
need not be) for any customization code that you write
(provide).

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

`custom-save-variables' _saves_ variables.

There are other `custom-*' and `customize-*' functions,
And most of the latter are also commands.  E.g., try
`M-x customize-set-variable'.

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.

setq just changes the variable value, so if there's a
:set operation associated with the variable then that
doesn't take place with setq.

setq is a default, basic, no bells & whistles setter
function.  Sometimes you want additional processing
to take place when you set an option value, hence
:set.

See https://emacs.stackexchange.com/a/106.

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

> is quite a nuisance for me.   Originally, having se-
> parate configuration files  like ".vm" or ".gnus.el" had the purpose not
> to clutter one's  "init.el" file  and to save time  when firing up Emacs
> without also starting Vm or Gnus.

You can have any number of separate config files,
which you load from your init file.  That's up to you.

> How do others solve these configuration problems?

Everyone does things differently, no doubt.  A general
recommendation (from me at least) is to separate all
code that you write, including all that customizes
user options and faces, from code that Emacs generates
automatically and saves in your `custom-file'.  So yes,
do you a separate `custom-file', and don't edit it.

Beyond that, you can do whatever else you like to/with
user options and faces, with whatever code you like,
in whatever files you like.  You generally don't need
to, but you can.

Really (IMO), regardless of whether you find the UI
of Customize clunky (and many of us do), the Emacs
functionalities behind options (defcustoms) and faces
(deffaces) is pretty solid and reliable.  It can take
some getting used to, but (1) it ensures that values
you provide are of the right type - so behavior
doesn't break, (2) it takes care of persisting your
preference settings across sessions, and (3) it takes
care of any additional actions that might be required
when an option value is initialized or set.