From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dr Rainer Woitok Newsgroups: gmane.emacs.help Subject: RE: [External] : Configuration files vs customization Date: Tue, 24 Jan 2023 18:31:41 +0100 Message-ID: <25552.5628.453256.171331@woitok.gmail.com> References: <25548.5130.933634.159947@woitok.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16429"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "help-gnu-emacs@gnu.org" To: Drew Adams Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 24 18:32:23 2023 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pKN9i-00042L-Tp for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 24 Jan 2023 18:32:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pKN99-0008NK-MG; Tue, 24 Jan 2023 12:31:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pKN98-0008N6-3a for help-gnu-emacs@gnu.org; Tue, 24 Jan 2023 12:31:46 -0500 Original-Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pKN96-0000Yo-8m for help-gnu-emacs@gnu.org; Tue, 24 Jan 2023 12:31:45 -0500 Original-Received: by mail-wr1-x42e.google.com with SMTP id e3so14598706wru.13 for ; Tue, 24 Jan 2023 09:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:in-reply-to:subject:cc:to:message-id :content-transfer-encoding:mime-version:date:from:from:to:cc:subject :date:message-id:reply-to; bh=jWEjV7Hk5aQK0UtzP7psgjBQPCCp7q6BatxEpC8QV1c=; b=UOl028A1iirkwWoVIwrsOfaZkkS+r935MAOwA4FM3Q0uxm0qoGOVqqx57WQJmXTkJ2 LBiSowSyPnG/L4zkrKbfN7s9OsDJbXELM35z0QkyuXVEWCDQbuUm9MXRmkBLpzc4qYjn jEJOCxgeR6vSduFyWiL6ocZ3n3SK5SqrnpxBG0mV13Yx8YlbZAUb7+3yPGZd+ucMoVCP LkJ8r6pD53GjLZF6g7SI4U3YCQv0/149509JcfJHZV+X/3bGATbU76xI63CSl5HXcw89 FGGfarlSqUMHVLrJe2BPEbzkuIH2ZFIEeqZn9uoAie5vP3t3jWyYJE8DG1xN2lT6KKsv lJBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:in-reply-to:subject:cc:to:message-id :content-transfer-encoding:mime-version:date:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=jWEjV7Hk5aQK0UtzP7psgjBQPCCp7q6BatxEpC8QV1c=; b=QkTOGVzg3DRNalC47VxOtKrRObaWrsIEg0pTYOaSp3HQEgyhyeW24ICwpayd05jSN/ BgL7i0HKae+nM1jdb7rZ4Mzo0/zYKc3bP7MKyRZaEpjCJUos8mTH+rTl3lftUPhT+sYB MaYUiF7GAQGKPCNzJPmhu/deetkgeh6FH/0tK7MK0VJXWQC40OhzuJJPxDmFkJOK4G1P uditxmpACCGUi3ZyVKa4l0JHgtf89LwnCAXwhJjNB5dLds6lhRfEJtpQa1N3fRklI8O8 R7nxsLRXc4RDGxVX9IkKz1LWOqoh22oBsBttDn4ZJM48NC5RgdI0bNiOHE1ndW/Jw5i0 uSqA== X-Gm-Message-State: AFqh2kqm3o8zzx1F+Bqs2dim4cKT5MkHhOTK1Uuin4Ui6s2YjcuFwXUc 3HkBY9fhFWbcMj6ykbMUUmw= X-Google-Smtp-Source: AMrXdXs83Hzui+ScFIthxlNMz+15NQpfii0s7aQ6ZFMUWbmbyw9R47ObA2SCvhlo+r+fQqzn9QWxKg== X-Received: by 2002:a5d:6a51:0:b0:2bb:e7ac:af73 with SMTP id t17-20020a5d6a51000000b002bbe7acaf73mr25870077wrw.42.1674581502200; Tue, 24 Jan 2023 09:31:42 -0800 (PST) Original-Received: from gmail.com (p200300df0743a4dd9b4c30e48303ca99.dip0.t-ipconnect.de. [2003:df:743:a4dd:9b4c:30e4:8303:ca99]) by smtp.gmail.com with ESMTPSA id v20-20020adfa1d4000000b00241cfe6e286sm2401731wrv.98.2023.01.24.09.31.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Jan 2023 09:31:41 -0800 (PST) X-Google-Original-From: Dr Rainer Woitok In-Reply-To: Msg of 2023-01-21 17:44:12 +0000 from drew.adams@oracle.com X-Mailer: VM 8.2.0b under 28.2 (x86_64-pc-linux-gnu) Received-SPF: pass client-ip=2a00:1450:4864:20::42e; envelope-from=rainer.woitok@gmail.com; helo=mail-wr1-x42e.google.com X-Spam_score_int: -31 X-Spam_score: -3.2 X-Spam_bar: --- X-Spam_report: (-3.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:142524 Archived-At: 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