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: Sat, 9 Jul 2016 14:54:18 +0000 (UTC) Message-ID: References: < <83vb0fgu83.fsf@gnu.org>> <<87k2gvhvql.fsf@users.sourceforge.net> <838txbgfgx.fsf@gnu.org> <837fcvgdho.fsf@gnu.org> > <<8360sehps4.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 1468076129 30770 80.91.229.3 (9 Jul 2016 14:55:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Jul 2016 14:55:29 +0000 (UTC) Cc: 23926@debbugs.gnu.org To: Eli Zaretskii , Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jul 09 16:55:16 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 1bLtf0-0004vg-Ve for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Jul 2016 16:55:15 +0200 Original-Received: from localhost ([::1]:51433 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLtf0-0002xU-Ch for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Jul 2016 10:55:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLteu-0002vm-Bi for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2016 10:55:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLteo-000497-AO for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2016 10:55:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60161) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLteo-000492-79 for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2016 10:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bLten-00052t-Ux for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2016 10:55: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: Sat, 09 Jul 2016 14:55:01 +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.146807607019353 (code B ref 23926); Sat, 09 Jul 2016 14:55:01 +0000 Original-Received: (at 23926) by debbugs.gnu.org; 9 Jul 2016 14:54:30 +0000 Original-Received: from localhost ([127.0.0.1]:44265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bLteI-000525-4C for submit@debbugs.gnu.org; Sat, 09 Jul 2016 10:54:30 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:17483) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bLteG-00051r-Dm for 23926@debbugs.gnu.org; Sat, 09 Jul 2016 10:54:28 -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 u69EsLQ1007677 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 9 Jul 2016 14:54:22 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u69EsKT9016500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Jul 2016 14:54:21 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u69EsJAE023105; Sat, 9 Jul 2016 14:54:20 GMT In-Reply-To: <<8360sehps4.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:120693 Archived-At: > Why change anything in the wording at all? It won't really change > what is being done, and won't prevent any confusion, because all this > "standard", "original", "default" etc. are not well defined anyway. Maybe you mean that they have not been well defined in our help for the user? Because the standard value is well defined in Customize, and it is referred to as such in the Customize UI. ("Original" and "default" are admittedly not so well defined.) What's missing is to call it by the same name in `C-h v'. And to provide some description/explanation in the doc, if it is not there now (I haven't searched just now). IOW, let's try to be clear with the labelling in `C-h v' - consistent with the names used in Customize. And let's try to let users of `C-h v' get more info about what they're looking at, to dispel confusion and answer questions. I think we should also have `C-h v' provide the underlying Lisp expression, at least on demand, just as Customize does. It's not great to show only a value without any indication of what it comes from. As for whether to call the value shown "standard value": IIUC, the standard value is: ;; the value given in the 'defcustom' declaration. ;; It is stored in the 'standard-value' property of the ;; option, in a cons-cell whose car evaluates to the standard ;; value. That wording is maybe not perfect. But IIUC, the value of the `standard-value' property is not the "standard value". Instead, it is a cons whose car _evaluates_ to the standard value. Its car is, I guess, the original Lisp expression from the defcustom. That is what needs to be made clear to users, I think, when showing them a value. Let them know that it is called the "standard value", and it is the result of re-evaluating, in the current context, the defining Lisp sexp for the option (which is used in the defcustom).=20 All of this is important for clarity. In particular, I think it is important that users understand the following, which is I guess what is behind Eli saying that the behavior is as expected: ;; The reason for storing values unevaluated: This is so you can have ;; values that depend on the environment. For example, you can have a ;; variable that has one value when Emacs is running under a window ;; system, and another value on a tty. Since the evaluation is only done ;; when the variable is first initialized, this is only relevant for the ;; saved (and standard) values, but affect others values for ;; compatibility. The premise of that last sentence is wrong, of course. It is done each time you use `C-h v' - to show you the "original" value. But the main point here is that it is a _feature_, not a bug, that the "standard value" is recomputed at any time from the original sexp. Why/how this is a feature is explained well in that paragraph. But without such an explanation, and especially just showing a value in `C-h v' and calling it the "original" value, we hurt instead of help users. ;; You can see (and modify and save) this unevaluated value by selecting ;; "Show Saved Lisp Expression" from the Lisp interface. This will ;; give you the unevaluated saved value, if any, otherwise the ;; unevaluated standard value. And that's the other piece that helps understanding. I think `C-h v' should show users that Lisp sexp - at least on demand. That will also help understanding of the standard value that is shown (and should be labeled as such): `C-h v' can say that this is the result of re-evaluating the Lisp sexp.