bug#4755: 23.1; case where `C-M-x' on defcustom doesn't seem to work

[Drew Adams <drew.adams@oracle.com>]

> > 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.
> 
> 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'?
> 
> 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?
 
> > I'm guessing that these problems arise because there is
> > a type mismatch.  But they still shouldn't manifest this
> > way, I think.
> 
> No, sorry about this type mismatch, it's a complete red
> herring. Let's simplify to:
> 
> (defcustom time (current-time-string)
>   "the time"
>   :type 'string)
> 
> 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.