From: Dr Rainer Woitok <rainer.woitok@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
Subject: RE: [External] : Configuration files vs customization
Date: Tue, 24 Jan 2023 18:31:41 +0100 [thread overview]
Message-ID: <25552.5628.453256.171331@woitok.gmail.com> (raw)
In-Reply-To: Msg <SJ0PR10MB54886AFCC58BACF9003BAB3BF3CA9@SJ0PR10MB5488.namprd10.prod.outlook.com> of 2023-01-21 17:44:12 +0000 from drew.adams@oracle.com
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
next prev parent reply other threads:[~2023-01-24 17:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-21 16:34 Configuration files vs customization Dr Rainer Woitok
2023-01-21 17:24 ` Jude DaShiell
2023-01-21 17:44 ` [External] : " Drew Adams
2023-01-21 19:04 ` Jude DaShiell
2023-01-21 20:54 ` Drew Adams
2023-01-24 17:31 ` Dr Rainer Woitok [this message]
2023-01-24 20:16 ` Drew Adams
2023-01-21 17:51 ` Thibaut Verron
2023-01-21 19:40 ` Tassilo Horn
2023-01-21 20:08 ` Jean Louis
2023-01-21 23:15 ` Eduardo Ochs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=25552.5628.453256.171331@woitok.gmail.com \
--to=rainer.woitok@gmail.com \
--cc=drew.adams@oracle.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.