From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mauro Aranda Newsgroups: gmane.emacs.bugs Subject: bug#63891: 29.0.91; customize-save-variable should not save all variables if a custom file exists Date: Sat, 28 Oct 2023 19:32:51 -0300 Message-ID: References: <1f269cb9-2cdf-4499-b68d-756d27648673@gmail.com> <874jicgu5w.fsf@gmx.de> <0ec5d535-c4e5-401f-8db7-fc4eb54f8517@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34427"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Eli Zaretskii , "wyuenho@gmail.com" , "63891@debbugs.gnu.org" <63891@debbugs.gnu.org> To: Drew Adams , Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 29 00:33:50 2023 Return-path: Envelope-to: geb-bug-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 1qwrsL-0008fe-0w for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 Oct 2023 00:33:49 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qwrsC-0005PZ-Ac; Sat, 28 Oct 2023 18:33:40 -0400 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 1qwrs2-0005O8-C7 for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2023 18:33:30 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qwrs2-0005a8-3x for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2023 18:33:30 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qwrsY-0000H1-0S for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2023 18:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mauro Aranda Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Oct 2023 22:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63891 X-GNU-PR-Package: emacs Original-Received: via spool by 63891-submit@debbugs.gnu.org id=B63891.16985324191009 (code B ref 63891); Sat, 28 Oct 2023 22:34:01 +0000 Original-Received: (at 63891) by debbugs.gnu.org; 28 Oct 2023 22:33:39 +0000 Original-Received: from localhost ([127.0.0.1]:39775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwrsB-0000GC-0M for submit@debbugs.gnu.org; Sat, 28 Oct 2023 18:33:39 -0400 Original-Received: from mail-qv1-xf35.google.com ([2607:f8b0:4864:20::f35]:57709) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwrs7-0000Fq-0n for 63891@debbugs.gnu.org; Sat, 28 Oct 2023 18:33:38 -0400 Original-Received: by mail-qv1-xf35.google.com with SMTP id 6a1803df08f44-66fbcc70c94so10510226d6.3 for <63891@debbugs.gnu.org>; Sat, 28 Oct 2023 15:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698532376; x=1699137176; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=JPtzCcyXyPkDrTspuw8+NPXkIRL2VZpuzNfDSP8UMoQ=; b=PnTcOpNh0IMyrG4yipQ/YrGCPkHqHA3MTmd/hGMrDi9Yk2NiAjpqheJFkYR+g3zgqW 7NqA7LpxvDXaki7HgzAxr7LdWVYyHLuD6Em4cxKCyO1kePnq6LznQd/Rb2WlHfOH85tx 0hYfs9LbtiM03kWBAhG9v4yCJaT2VVt7+vgWqgJXubR31iDFJc4rqdlPSaiJU8rlSXw0 Ccdj7Ruhu0MO3n7HfMP/rwUXpc7TY6Qr75BtZz1TuniJtfybSP12wFbD1X2pVNUZeZeB RpGMijiicAUeoTNMf1nB8/MmKlFhZFY128qyeGmeWvZT3YUk/aZJjjSZDC/9OVZ/n9HL JenQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698532376; x=1699137176; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JPtzCcyXyPkDrTspuw8+NPXkIRL2VZpuzNfDSP8UMoQ=; b=YWCIVd4w165/qlEx74jxpc8Qe+B+gdOA5zb/y6IWM+CVnSS1cVdForDzGXTLmhQ+po 0ujWDo/cqfS63BEmMChRwcCr67WL+M5vQmaogwIvIQl8To+AaVYQ07czUZxiRIhj1iT9 A+/E9w4gxiGbAyp1PMHQc9Q3CVp0DudJaZ9PbRkfn3WqPwr0wOBNFdn5TN9LWgI3oeNX ImBowSZxfrWI8MIcIuzzxBAeVQV7F7fDrZ6LbgSuhLbqiDYP5sE/rLNKU+5OmobVU5dR C+wGIsxVKyE0w68C4c4OlB92sncO5/UJaZKsfvQ8WVOmS10Cwpuhd6ISwbrUGxdJjzZc NR6w== X-Gm-Message-State: AOJu0YzRxK03UPl2t4VAoPA5HlvZQTwU4KizydQzSu8pjoAWxzAC6x0H zB7Kr2XbP8Eq5p/Z7RqA6Rg= X-Google-Smtp-Source: AGHT+IFBLnUrrLhVjAkzzyB4FnaxGyNsBcAAmyCk3bOuiyaP1fLLUdubIIsd5VR7M1Dv987gn5/Gaw== X-Received: by 2002:a05:6214:5006:b0:66d:48e4:9928 with SMTP id jo6-20020a056214500600b0066d48e49928mr8756579qvb.12.1698532375853; Sat, 28 Oct 2023 15:32:55 -0700 (PDT) Original-Received: from [192.168.0.234] ([152.168.142.156]) by smtp.gmail.com with ESMTPSA id k15-20020a05621414ef00b0065b14fcfca6sm1971913qvw.118.2023.10.28.15.32.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 28 Oct 2023 15:32:55 -0700 (PDT) Content-Language: en-US In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:273472 Archived-At: On 28/10/23 15:22, Drew Adams wrote: >> if packages are going to be changing this 2 options >> without asking the user about it, why do the packages >> need to lie to Custom saying that the user asked for >> that?  Why don't just setq, add-to-list or modify it >> some other way? At least that way Custom would know >> the truth, the setting was changed outside of Customize. >> >> That's why I don't understand what is the expectation >> about Custom here (apart from being less naive when >> saving the custom-file).  The code is modifying a user >> option and tells Custom that it was upon the user >> request, when in fact it hasn't. >> >> Finally, have you considered the approach of having >> the user option plus another variable which packages >> should modify when desired? Then the code could merge >> the user settings with the package settings. > > Hi Mauro, > > My 2 cents about such things - > > 1. Libraries can usefully modify user options.  They > just need to make users aware of this happening, so > that taking advantage of this is a user choice. > > In particular, libraries can define commands whose > purpose includes changing option values - sometimes > even saving such changes immediately.  To me, this > isn't a no-no.  What is a no-no is changing an > option value behind a user's back, and a fortiori > saving such a change - big NO-NO. Of course, and we agree.  I sent a message yesterday asking why didn't the code just used customize-set-variable, which is one of the functions that Custom gives for libraries when they want to change the value of some user option for the session, upon user request.  That's why I'm raising the point that this change is happening behind the user's back. But it seems to be the way that these particular user options, connection-local-profile-alist and connection-local-criteria-alist, are supposed to be used by packages.  IOW, it seems to me that this is not specific to Tramp.  For example: emacs -Q (progn   (require 'files-x)   (setq old-connection-local-profile-alist connection-local-profile-alist)   (require 'eshell)   (equal old-connection-local-profile-alist connection-local-profile-alist)) That evaluates to nil.  This is not happening via some command. Of course, the libraries might need to change the value to work correctly, but that's why I'm asking what's the expectation about Custom after the change, because telling Custom this happened upon user request is not true.  Another bad consequence is this: M-x customize-option RET connection-local-profile-alist State shown is: SAVED and set But of course, if you visit custom-file, you'll see no such reference to connection-local-profile-alist.  This should show that this is not the way custom-set-variables is supposed to be used. > Wrt your last paragraph above: That's the approach > that Emacs generally takes.  It's OK, though it's a > bit of a kludge.  More importantly, users can _want_ > to modify an option value on the fly, as opposed to > modifying its non-option shadow/stand-in variable. OK, that's something I haven't considered. > 2. Emacs should make available features I noted in > previous posts, such as a function to consider a > change to an option value (by program) to not be a > change.  This lets code change a value but not > have Customize consider that a change has been > made - so the change won't be saved automatically > or reported as having occurred. I wonder what does this mean in terms of the possible states for a user option.  AFAICT, none of the current possible states (STANDARD, SAVED, CHANGED, SET) fit in your description. STANDARD: No, standard value and current value don't match. SAVED: No, that setting wasn't saved. CHANGED: No, because you're saying that Custom shouldn't consider the change. SET: No, because the code needs to use customize-set-variable, but that wouldn't be Custom ignoring the change. > 3. Emacs should also make available the ability for > `defvar' (or a new macro) to use the features of > `defcustom'.  In particular, this includes :set and > :type, and it includes the ability to persist the > value. > > The difference between this and `defcustom' is that > uch variables aren't recognized by Emacs as user > options.  Users can't use the Customize UI or > `set-variable' with such vars.  `C-h v' provides no > `customize' link, etc. This sounds interesting. > I proposed #3 to emacs-devel@gnu.org back in 2009: > > https://lists.gnu.org/archive/html/emacs-devel/2009-10/msg00668.html > > I sent a patch for #3 as bug #27348 (closed by Lars, > saying that no one would want such a feature): > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27348 > > That patch, with a couple trivial tweaks, is still > valid against Emacs 29, I believe. > > It adds keyword `:not-custom-var' to `defcustom'. > If its value is non-`nil' then the variable doesn't > satisfy `custom-variable-p', which means it's _not > available for interactive use_ (completion, > `set-variable', `apropos-user-option' output, etc.). > IOW, such a variable is for code more than for user > configuration. > > The patch also defines macro `defvarc', which is > just `defmacro' with `:not-custom-var' set to `t'. > > The `defcustom' keywords etc. could have just been > added to `defvar' for optional use.  I defined a > separate macro just to not interfere with any > existing uses of `defvar'. > > In sum, this uncouples interactive customization > from the other features that Customize offers, in > particular, type-checking and persistence, and it > provides those features for non-option variables. > > The ability to type-check, provide `:set' and > `:initialize' trigger functions, automatically > `:require' libraries, add links to doc, associate > with one or more `:groups', etc.  These are useful > things to be able to do with at least some defvars, > not just with defcustoms. > > Similarly, the ability to persist non-option vars > in a user's custom file can be useful.  This alone > is a frequent question, to which the answer has > been `savehist-additional-variables', `desktop.el', > or Bookmark+ variable-list bookmarks. > > The patch also includes a macro `with-user-vars', > which temporarily lets a set of variables be > customizable.  That is, it lets you treat a > `defvarc' variable as if it were a `defcustom' > option.  So if you want, you can use the Customize > UI to change a defvarc's value, or define commands > that use (e.g. complete) `defvarc' variable names. Thank you for the links and the explanation.  I'll take the time to read them. Just by reading your explanation, I don't think I understand if just by using something like your description of 'defvarc' would solve the issue of having to combine user's customizations with a package setting by using two different variables.