Configuration files vs customization

Configuration files vs customization

[Dr Rainer Woitok]

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

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 ...)'.   The lack of this flexibi-
lity 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.

So being forced to put more or less  all application specific configura-
tion into one big "custom.el" file which on top of all  does only accept
constants as values 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.

How do others solve these configuration problems?

Sincerely,
  Rainer

Re: Configuration files vs customization

[Jude DaShiell]

I prefer configuration to customization since once a file is in place it's
shareable so if I get something wrong in configuration it can be checked
by other eyes.  With customization especially in the case of the o-p,
there's no way possible to clean that up outside of customization and
likely no way for others to examine current state of customization and
give good advice on how to correct it to get things working.



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, Dr Rainer Woitok wrote:

> 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".
>
> 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 ...)'.   The lack of this flexibi-
> lity 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.
>
> So being forced to put more or less  all application specific configura-
> tion into one big "custom.el" file which on top of all  does only accept
> constants as values 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.
>
> How do others solve these configuration problems?
>
> Sincerely,
>   Rainer
>
>

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.

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

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

Re: Configuration files vs customization

[Tassilo Horn]

Dr Rainer Woitok <rainer.woitok@gmail.com> writes:

Hi Rainer,

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

As Drew already pointed out, defcustom has several properties like :set
which might do stuff when the variable is customized and which are not
executed when it's only set with `setq'.  In very recent Emacsen (29+),
there's `setopt' which has the syntax of `setq' but behaves more like
`custom-set-variables'.

Bye,
Tassilo

Re: Configuration files vs customization

[Jean Louis]

* Dr Rainer Woitok <rainer.woitok@gmail.com> [2023-01-21 11:34]:
> 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.

I use separate custom.el file where I never look inside.

I have ~/.emacs.d/init.el

which has on its end:

(load "~/.emacs.d/custom.el")

and I have variable:

 '(custom-file "~/.emacs.d/custom.el")

in "custom.el"

So that way you will separate custom.el and not have init.el
cluttered, and you can separate other options too.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

RE: [External] : Configuration files vs customization

[Drew Adams]

> doesn't the evaluation process of setq evaluate current configuration and
> dependencies?

No.  It just assigns the variable a value.

> If it doesn't that with that third t option would be a
> useful service.

setq is as old as Lisp.  And it already accepts
more than two args - try `C-h f setq'.

And no, setq isn't limited to having anything to
do with any kind of configuration or dependencies.

Re: Configuration files vs customization

[Eduardo Ochs]

On Sat, 21 Jan 2023 at 13:34, Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
> (...)
>
> 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".
>
> (...)
>
> How do others solve these configuration problems?

Hi Rainer,

I use customize a bit, but I avoid it as most as possible. My ~/.emacs
has (something equivalent to) these two lines,

  ;; See: (info "(emacs)Saving Customizations")
  ;;     (find-file "~/.emacs.custom")
  (setq custom-file "~/.emacs.custom")
  (load custom-file)

and in most cases I "customize" packages by putting in my ~/.emacs
blocks of code consisting of a setq preceded by elisp hyperlinks that
point to my notes about that variable.

My experiments with alternatives to customize are described here:

  http://angg.twu.net/eev-customize.html

Cheers,
  Eduardo Ochs
  http://angg.twu.net/#eev

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

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.