RE: [External] : Configuration files vs customization

[Jude DaShiell]

doesn't the evaluation process of setq evaluate current configuration and
dependencies?  If it doesn't that with that third t option would be a
useful service.



Jude <jdashiel at panix dot com> "There are four boxes to be used in
defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Sat, 21 Jan 2023, Drew Adams wrote:

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