From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#23926: defcustom with STANDARD= gives confusing results Date: Sun, 10 Jul 2016 10:18:29 -0700 (PDT) Message-ID: References: <<<>>> <<<<83vb0fgu83.fsf@gnu.org>>>> <<<443f2e44-5167-48e7-abc6-cce1e243461e@default>>> <<<8337nihpdw.fsf@gnu.org>>> <> <<83zipqg3e3.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1468171185 7433 80.91.229.3 (10 Jul 2016 17:19:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jul 2016 17:19:45 +0000 (UTC) Cc: 23926@debbugs.gnu.org, npostavs@users.sourceforge.net To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 10 19:19:31 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bMIOA-0000vv-SZ for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Jul 2016 19:19:31 +0200 Original-Received: from localhost ([::1]:56062 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMIO7-0000Ro-1a for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Jul 2016 13:19:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40240) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMINm-0000Hp-1Z for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2016 13:19:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bMINi-0007Tf-ML for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2016 13:19:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33160) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMINi-0007Ta-I2 for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2016 13:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bMINi-0000hp-Eb for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2016 13:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Jul 2016 17:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23926 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23926-submit@debbugs.gnu.org id=B23926.14681711212680 (code B ref 23926); Sun, 10 Jul 2016 17:19:02 +0000 Original-Received: (at 23926) by debbugs.gnu.org; 10 Jul 2016 17:18:41 +0000 Original-Received: from localhost ([127.0.0.1]:45496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bMINN-0000hA-Bt for submit@debbugs.gnu.org; Sun, 10 Jul 2016 13:18:41 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:39575) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bMINJ-0000gi-JF for 23926@debbugs.gnu.org; Sun, 10 Jul 2016 13:18:38 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u6AHIVEG000418 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 10 Jul 2016 17:18:31 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u6AHIVSO026760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 10 Jul 2016 17:18:31 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u6AHIVle015090; Sun, 10 Jul 2016 17:18:31 GMT In-Reply-To: <<83zipqg3e3.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:120791 Archived-At: > > > > 2. Is it not a bug that Customize tells you that the value > > > > was changed outside Customize? In what way was it > > > > changed outside Customize? In fact, it was not even > > > > changed. > > > > > > It was changed, > > > > The option value was changed? I don't think so. >=20 > Yes, it was changed, because the value returned by the function > changes each time it's called. What function? And what occurrence of calling it do you think is responsible for this characterization of the value having been changed outside Customize? The fact is that the user did NOT change the value outside customize. And in fact, the value has NOT been changed. It is what it was when the defcustom was evaluated. The responsible code is `custom-variable-state', specifically this part: (setq tmp (get symbol 'standard-value)) (if (condition-case nil (and (equal value (eval (car tmp))) (equal comment nil)) (error nil)) 'standard 'changed) That tests whether the current value (var VALUE here), which in this case came from (default-value 'time), is equal to the result of RE-evaluating the defining defcustom sexp, (current-time). And of course it is not equal, because time passes... The reason it is not unequal is NOT because something has changed the option value outside Customize. The option value has not been changed at all. What "changes" here is the result of evaluating the initial sexp. IOW, the "changed-outside-Customize" test used is too simplistic. =20 Note that the code does try to correct its own logic in some cases - for example, in this case: ;; The value was originally set outside ;; custom, but it was set to the standard ;; value (probably an autoloaded defcustom). This but shows another case where its too-simplistic logic trips it up, but this case is not being handled (compensated for). Nothing, including anything the user has done, has changed the value outside Customize. But the customize code is, so far, unable to recognize that. The code blithely assumes that evaluating what `custom-get' returns represents the original value, whereas what it returns is the result of RE-evaluating the original sexp. That is precisely the point of this bug. The code correctly compensates in the case mentioned in the comment cited above. But it does not compensate in the case demonstrated by the simple recipe Noam provided: (defcustom time (current-time-string) "the time" :type 'string) A _single_ evaluation of that defcustom should not throw Customize off into thinking that the value has been changed outside Customize. And that is what is happening, because its determination of "changed outside Customize" is too simplistic. > > See above. Do you still think this is not a bug? >=20 > Of course, I do. Maybe you don't realize how many times > Emacs evaluates the value of a defcustom, but I do. Please don't patronize us. Everyone respects your understanding of Emacs and Customize, but in this case I think you are wrong. It is not a question of "how many times Emacs evaluates the value of a defcustom". It is about Emacs interpreting a difference in the value returned by evaluating the defcustom defining sexp from the current value as always representing a change in the value of the variable (and outside Customize, to boot). I think we understand what is happening. For us, telling the user that the value has CHANGED from its original setting is clearly wrong, since the VALUE has not changed. And saying that it was changed outside Customize is doubly wrong, since no user code or user action has done anything to the value anywhere, including outside Customize. This is Customize stepping stepping on its own feet, and as a result misleading users. As for _fixing_ this part of the bug (the misleading state): I don't see a solution other than doing either of these, but other ideas are welcome: 1. Save also the original _value_ and compare the current value with that, instead of with the result of reevaluating the standard-value sexp. 2. Try to better characterize the state to users. Instead of calling it changed-outside-customize, somehow indicate what it really means: the current value is not the same as what you get by reevaluating the defining sexp. And then there is the other part of this bug: what to do for `C-h v'. I'll speak to that in a separate reply.