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#4755: 23.1; case where `C-M-x' on defcustom doesn't seem to work Date: Tue, 5 Jul 2016 11:20:33 -0700 (PDT) Message-ID: <53a1717b-a62f-43af-9864-4c8b44bd7469@default> References: <340F1FE0FD29493A984C1582F2B10756@us.oracle.com> <87poqsd8lc.fsf@users.sourceforge.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1467745197 4594 80.91.229.3 (5 Jul 2016 18:59:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Jul 2016 18:59:57 +0000 (UTC) Cc: 4755@debbugs.gnu.org To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 05 20:59:42 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 1bKVZO-0004II-Cj for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Jul 2016 20:59:42 +0200 Original-Received: from localhost ([::1]:57382 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKVZN-0000ef-Ns for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Jul 2016 14:59:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41315) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKUy2-0006fL-9G for bug-gnu-emacs@gnu.org; Tue, 05 Jul 2016 14:21:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKUxy-0006CN-3u for bug-gnu-emacs@gnu.org; Tue, 05 Jul 2016 14:21:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54475) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKUxy-0006CH-0G for bug-gnu-emacs@gnu.org; Tue, 05 Jul 2016 14:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bKUxx-0002dN-P6 for bug-gnu-emacs@gnu.org; Tue, 05 Jul 2016 14:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Jul 2016 18:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 4755 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: unreproducible Original-Received: via spool by 4755-submit@debbugs.gnu.org id=B4755.146774285010100 (code B ref 4755); Tue, 05 Jul 2016 18:21:01 +0000 Original-Received: (at 4755) by debbugs.gnu.org; 5 Jul 2016 18:20:50 +0000 Original-Received: from localhost ([127.0.0.1]:38579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKUxl-0002cq-LV for submit@debbugs.gnu.org; Tue, 05 Jul 2016 14:20:49 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:48293) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKUxj-0002cd-I3 for 4755@debbugs.gnu.org; Tue, 05 Jul 2016 14:20:48 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u65IKefH028587 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jul 2016 18:20:41 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u65IKeHQ031650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jul 2016 18:20:40 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u65IKYgp016360; Tue, 5 Jul 2016 18:20:39 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] 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:120455 Archived-At: > > The "original value" should not change, and especially not just > > by using `C-h v'. It is wrong to say the "original value was" > > something that it never was and still is not! I don't see any > > evidence that that behavior is "expected" or is by design. > > > >> So perhaps the thing to be fixed is that describe-variable > >> should say "Standard value" rather than "Original value". > > > > I don't see how that would help. >=20 > It will help by not misleading you into thinking that Emacs is showing > you the original value. It's not showing you the original Lisp expression either, and users will not have a clue what "standard value" means. (I'm not sure I really do.) It is apparently a value obtained by reevaluating the defcustom. > > The doc you quote says that the std value is recomputed > > _by Customize_, by reevaluating the saved expression. > > Why should that affect `C-h v'? >=20 > They both use the same `standard-value' as the "original" > (but yes, I only know this because I read the code). Yes, I know. But is that TRT? If it is then the help should make much clearer what it is showing (and why). IOW, it is showing what the value WOULD BE if the original Lisp expression were reevaluated in the current context. If it's doing that, maybe it would be good to say that that is what it's doing, and to also show the original Lisp sexp? =20 > > I'm guessing that these problems arise because there is > > a type mismatch. But they still shouldn't manifest this > > way, I think. >=20 > No, sorry about this type mismatch, it's a complete red > herring. Let's simplify to: >=20 > (defcustom time (current-time-string) > "the time" > :type 'string) >=20 > Basically the problem stems from passing a non-pure expression > (meaning one that doesn't always give an `equal' result) as the > STANDARD argument to defcustom. Actually, since so many places seem to > assume they will always get the same result, I wonder why the > expression rather than the result of evaluating it is being stored. I can see why the expression would be stored. I'm not sure I see why the expression is not shown to users via `C-h v', and I'm not sure why the expression is reevaluated by `C-h v' (see above). But a (copy-sequence...) sexp is pure as far as the top-level sequence structure is concerned. The individual list elements are shared, OK, but the top-level list structure is not - it is new conses. I don't think that's the problem. The problem is that the defining sexp gets reevaluated, so the new `foo' sequence gets copied by reevaluating (copy-sequence...), and the result is shown as the "original" (or standard) value of `toto'. That can only be confusing to users, I think.