From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#23926: defcustom with STANDARD= gives confusing results Date: Mon, 11 Jul 2016 21:52:15 +0300 Message-ID: <83bn24c8io.fsf@gnu.org> References: <<<>>> <<<<83vb0fgu83.fsf@gnu.org>>>> <<<443f2e44-5167-48e7-abc6-cce1e243461e@default>>> <<<8337nihpdw.fsf@gnu.org>>> <> <<83zipqg3e3.fsf@gnu.org>> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1468263264 17207 80.91.229.3 (11 Jul 2016 18:54:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Jul 2016 18:54:24 +0000 (UTC) Cc: 23926@debbugs.gnu.org, npostavs@users.sourceforge.net To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jul 11 20:54:13 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 1bMgLN-0000d7-9A for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Jul 2016 20:54:13 +0200 Original-Received: from localhost ([::1]:35576 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMgLM-0006QU-9V for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Jul 2016 14:54:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMgLG-0006QD-1A for bug-gnu-emacs@gnu.org; Mon, 11 Jul 2016 14:54:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bMgLC-0002N3-Pr for bug-gnu-emacs@gnu.org; Mon, 11 Jul 2016 14:54:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34880) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMgLC-0002Mw-Lk for bug-gnu-emacs@gnu.org; Mon, 11 Jul 2016 14:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bMgLC-0001vu-DK for bug-gnu-emacs@gnu.org; Mon, 11 Jul 2016 14:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Jul 2016 18:54: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.14682631837355 (code B ref 23926); Mon, 11 Jul 2016 18:54:02 +0000 Original-Received: (at 23926) by debbugs.gnu.org; 11 Jul 2016 18:53:03 +0000 Original-Received: from localhost ([127.0.0.1]:47217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bMgKF-0001uY-Gb for submit@debbugs.gnu.org; Mon, 11 Jul 2016 14:53:03 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54993) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bMgKD-0001u2-Kr for 23926@debbugs.gnu.org; Mon, 11 Jul 2016 14:53:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bMgK5-0002E6-6P for 23926@debbugs.gnu.org; Mon, 11 Jul 2016 14:52:56 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51844) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMgK5-0002Dt-2X; Mon, 11 Jul 2016 14:52:53 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4085 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bMgK1-0002om-2n; Mon, 11 Jul 2016 14:52:51 -0400 In-reply-to: (message from Drew Adams on Sun, 10 Jul 2016 10:18:29 -0700 (PDT)) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:120868 Archived-At: > Date: Sun, 10 Jul 2016 10:18:29 -0700 (PDT) > From: Drew Adams > Cc: npostavs@users.sourceforge.net, 23926@debbugs.gnu.org > > > > The option value was changed? I don't think so. > > > > Yes, it was changed, because the value returned by the function > > changes each time it's called. > > What function? current-time-string, of course. > And what occurrence of calling it do you think is responsible for > this characterization of the value having been changed outside > Customize? The second one. > The fact is that the user did NOT change the value outside > customize. The message doesn't say it was the user. Emacs doesn't know who changed the value. > And in fact, the value has NOT been changed. Of course, it has changed. Every time current-time-string is called it returns a different value. A defcustom's value is evaluated at least twice, and in this case the second call yields a different value. That's why you see the note about changing. > 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. No, it isn't. It does its job. If you want to avoid the note, if the note annoys you, don't write such code. > 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. There's no bug. This is how this stuff is supposed to work. I'm not going to endorse any significant changes there because of such marginal use cases.