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:23:13 -0700 (PDT) Message-ID: <33b89b73-733f-42a1-9d26-eb0ed3c8d9cc@default> 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 1468171467 11610 80.91.229.3 (10 Jul 2016 17:24:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jul 2016 17:24:27 +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 Sun Jul 10 19:24:14 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 1bMISj-0002hA-CM for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Jul 2016 19:24:13 +0200 Original-Received: from localhost ([::1]:56093 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMISi-00032Q-Mr for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Jul 2016 13:24:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41630) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMISc-000326-GV for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2016 13:24:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bMISY-0000Ii-8m for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2016 13:24:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33168) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMISY-0000Id-50 for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2016 13:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bMISY-0000pn-19 for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2016 13:24: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:24: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.14681714043165 (code B ref 23926); Sun, 10 Jul 2016 17:24:01 +0000 Original-Received: (at 23926) by debbugs.gnu.org; 10 Jul 2016 17:23:24 +0000 Original-Received: from localhost ([127.0.0.1]:45505 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bMIRw-0000oz-Af for submit@debbugs.gnu.org; Sun, 10 Jul 2016 13:23:24 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:40005) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bMIRt-0000ol-P5 for 23926@debbugs.gnu.org; Sun, 10 Jul 2016 13:23:22 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u6AHNFSQ003134 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 10 Jul 2016 17:23:15 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u6AHNF79025731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 10 Jul 2016 17:23:15 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u6AHNEMw017682; Sun, 10 Jul 2016 17:23:14 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: aserv0021.oracle.com [141.146.126.233] 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:120793 Archived-At: > 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. >=20 > 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. ... > 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: >=20 > ;; 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > ;; 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. >=20 > And that's the other piece that helps understanding. I think > `C-h v' should show users that Lisp sexp - at least on demand. >=20 > 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. Here are a couple proposals for how to fix the `C-h v' part of this bug. Others are welcome. 1. Not print the "original value" at all, as was the case before Emacs 24. Let users get such info from Customize. 2. Like #1, but give users a hint that such info is in fact available from Customize. My suggestion here would be to not only remove printing the "original value" but to change the text "You can customize this variable.", where `customize' is a link to Customize, with this text, all of it a link with the same target: Customize or inspect (or possibly "Inspect or customize"). The point is for the link text to indicate that the target (Customize for the option) is not only for changing the value but also for finding out more about the option and its customization. 3. Like #1 and #3, but also provide a (toggle) link to show the defining Lisp sexp for the default value or, if it is shown, to reevaluate it and show the result: Show Lisp sexp defining the default value (if not shown) and Reevaluate (if shown - displayed just above it, in place of "Show Lisp sexp defining the default value"). I think any of these would improve the `C-h v' doc, especially for this situation where the Lisp sexp can return different values. If you decide to go for any of these approaches I could work on a patch. (Note that this mail is only about the `C-h v' part of the bug. It does not address the part that concerns how the Customize UI talks about the state - see my previous message about that part.)