bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results

[Drew Adams]

> 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). 

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.