Re: Configuration files vs customization

[Thibaut Verron]

Hi,

Le sam. 21 janv. 2023 à 17:34, Dr Rainer Woitok <rainer.woitok@gmail.com> a
écrit :

> Greetings,
>
> in the course  of my transition  from XEmacs  to Emacs  I meanwhile have
> reached the point  of getting Vm running under Emacs.   But my first at-
> tempt utterly failed.   After some  experimenting  and checking variable
> values with "C-h v" I came to the conclusion that at least in some vari-
> ables' descriptions  the remark "You can customize this variable" really
> meant "You HAVE TO customize this variable".
>

Customize may do additional things than just setting the variable, usually
reloading a function or setting additional variables. Most frequently,
setting the variable before loading the package would have the same effect.


>
> So eventually I removed  everything customizable  from my ".vm" configu-
> ration file and customized it instead.  And then Vm worked as expected.
>
> Why is that?   Do I have to use "defvar" rather than "setq" in my ".vm"
> configuration file to mark these variables as dynamically bound?
>

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


Do you refer to the fact that values are not evaluated before being stored
in variables? If so, according to the documentation, you can set the third
member to t to ask for evaluation "now".


> 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.
>
> function "custom-set-variables" writes into my "custom.el" file, putting
> a call to "custom-set-variables"  together with the Vm specific customi-
> zation directly into configuration file ".vm" is not expected to work.
>

custom-set-variables does not write anything, but it serves as the target
for when the customize interface writes. I don't know if there would really
be problems with having more than one block, except for not knowing where
new customizations are written.

Less hazardous, you can use customize-set-variable as a replacement for
setq (but for only one variable) with the additional customize code.

For users of use-package, the parameter :custom allows to customize
variables from within the use-package macro, thus keeping them nicely
sorted in the init file(s). This is what I personally do.

Best wishes,
Thibaut