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: Sun, 29 Oct 2023 07:33:29 -0300 Message-ID: <6a0bbea0-eb6e-48bb-9aa6-d86be8e5d228@gmail.com> 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="29647"; 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 11:34:55 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 1qx38A-0007Rh-D0 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 Oct 2023 11:34:54 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qx37n-0002QY-9M; Sun, 29 Oct 2023 06:34:31 -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 1qx37m-0002QP-58 for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2023 06:34: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 1qx37l-00007N-SA for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2023 06:34:29 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qx38I-0003Sv-3q for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2023 06:35: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: Sun, 29 Oct 2023 10:35:02 +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.169857565513256 (code B ref 63891); Sun, 29 Oct 2023 10:35:02 +0000 Original-Received: (at 63891) by debbugs.gnu.org; 29 Oct 2023 10:34:15 +0000 Original-Received: from localhost ([127.0.0.1]:40410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qx37X-0003Rj-Ar for submit@debbugs.gnu.org; Sun, 29 Oct 2023 06:34:15 -0400 Original-Received: from mail-yb1-xb2b.google.com ([2607:f8b0:4864:20::b2b]:45285) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qx37S-0003RJ-QB for 63891@debbugs.gnu.org; Sun, 29 Oct 2023 06:34:13 -0400 Original-Received: by mail-yb1-xb2b.google.com with SMTP id 3f1490d57ef6-d9ca471cf3aso2905911276.2 for <63891@debbugs.gnu.org>; Sun, 29 Oct 2023 03:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698575612; x=1699180412; 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=YDMGsMaclhvjOFJTcD+kDJLZsPrDvm0UTgvuXr+j+JM=; b=gZgX9cNzjuITCRsIF3g8CNZ4gG2vZLkmM7rrj8AKaABiksoeGD4atZhF1zAbGFjRVV 8X4a+HT2KlHPir0GqGs8lHXDQ8WROPS+R4hbnPS8073hUMsC/iYfZ/0dUW7bp0DgaWTw vdmCAhwSyF1xVLctzfKAC9vMjrzHSPiWJoav5OMvrfTfe4GiE2An7E+MnNsNmh1zflun VphX1224+DS0o4xyqm7lZgRW8z0jwGCn8TzgaYS1daf8dNfdHVWJhFZu/PqIT516R//P yxH10p3VFo2hyGpVp3D5xUDEWPw4hoVR3hjn37LMD+qQ6NxJQ3VgdKyN3cfxXFOlkqBa nqsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698575612; x=1699180412; 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=YDMGsMaclhvjOFJTcD+kDJLZsPrDvm0UTgvuXr+j+JM=; b=pnjHeAh4Ydt6/DW2uR/VYU07MkCBQNUO8QpxxlUnTZyU+v74K70m2BzvsHbEa8+p4B /z/jRwJevLZcUJm5NvZgKRKrezA1ThHLXikZooC9DYdeHQ3bnVr+P6ErZh+lX07CzUgh eIZish4OSyaVZpukSwIHDDUQ1tm0NKoxrO1oWGFp7zEIk2EQky1gbaJZ5qfwcINNPSi+ gMnvikNAGCEYB/SqLVtkrvLUm7Fc+YEzHOPS0y21TryCG76Ysr1er/NGvazW8qaHyRdg wjzHhsxmcqG2O0ACYc+Q+a5kKwCodTLlx9CYsYhQOzyXRQO3Y71t7/S4rvJS26Zwdv/i MecA== X-Gm-Message-State: AOJu0YxtKVmJgis5uhyWy+/+yukFEHBrtiLwg3OOYfaq7DNzFDtmVTae ga1ueZ6R3SV8fG5DXb7pMME= X-Google-Smtp-Source: AGHT+IENmXCqeNuNQVEPyXXMvWqTZojKI2AFx3X11eVmB08EcBj2JaYUPr+U9fHET5oNwziWpPQ7Yg== X-Received: by 2002:a25:2f4d:0:b0:d9c:2420:5d2e with SMTP id v74-20020a252f4d000000b00d9c24205d2emr6642551ybv.53.1698575612475; Sun, 29 Oct 2023 03:33:32 -0700 (PDT) Original-Received: from [192.168.0.234] ([152.168.142.156]) by smtp.gmail.com with ESMTPSA id j205-20020a2523d6000000b00da05d771097sm2605674ybj.22.2023.10.29.03.33.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 Oct 2023 03:33:31 -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:273488 Archived-At: On 28/10/23 23:20, Drew Adams wrote: >>  > 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. > > I use my library `cus-edit+.el', which changes > some of the `cus-edit.el' code.  See, e.g., > function `custom-consider-variable-unchanged'. > Doc string: > >   Consider this variable as being unchanged now. >   This does not save the current value; it just >   considers the value to be unchanged.  If no >   further changes are made to this variable, then >   after doing this, `customize-customize' will not >   display this variable, since it was considered >   unchanged. 'customize-customized', right? > The cus-edit+.el code is here: > > http://www.emacswiki.org/emacs-en/download/cus-edit%2b.el I tried to visit this link with eww, but got 404 Not Found. > And here is some info about it: > > http://www.emacswiki.org/CustomizingAndSaving#CustomizePlus Same here. Anyway, I read custom-consider-variable-unchanged, and it looks to me that it would have the same problem when saving an unrelated variable, because of the way custom-save-all works.  I want to work on improving the saving mechanism so that problem disappears, but ISTM that this bug report is about a different bug: a misuse of custom-set-variables. > About considering some customized state to be > "unchanged", see this post to bug 19328 thread. > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19328#47 Thank you.  I read the "Dealing with Spurious Changes" section from cus-edit+.el.  Part 2 and Part 3 sound interesting to me.  It seems to me that adding an ignore mechanism would be useful, in general. > I don't claim that what I did in `cus-edit+.el' > is the only or the best way to fix the problems > it addresses.  It might be a starting point for > someone with a better idea or understanding of > the custom code/behavior. It's certainly useful to me to know about your approach. I guess at this point I need to hear from Michael to understand better about this 2 defcustoms in particular, and what are the expectations after modifying them.  I certainly wish the code goes back to using customize-set-variable or something similar, rather than custom-set-variables.