[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing
From: |
Drew Adams |
Subject: |
bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results |
Date: |
Sat, 9 Jul 2016 14:09:17 +0000 (UTC) |
> > (defcustom time (current-time-string) "the time" :type 'string)
> >
> > Then try to M-x customize-options RET time RET, it will show with
> > state "CHANGED outside Customize." Similarly, doing <f1> v time RET
> > shows the "original value" as the current time, not the actual value
> > when `time' was defined.
>
> Why is this a bug? Seems to be expected behavior to me.
Noam can provide his explanation. For my part:
1. The "original value" shown by `C-h v' is not the original
value. In fact, it might never have been the value of the
variable, and it might never become its value.
This much is a doc problem. What is shown is the result
of evaluating, in the current context, the original,
defining Lisp sexp.
And if this is really what we want to show then it would
be good to also show what that Lisp sexp is. If it is
large then provide a button/link to show it completely.
And it might be good to also show the actual original
value, i.e., the value when the variable was first set,
however it was set. (The original value could have
been set without evaluating the original Lisp sexp of
the defcustom.)
2. Is it not a bug that Customize tells you that the value
was changed outside Customize? In what way was it
changed outside Customize? In fact, it was not even
changed.
How about the reverse: Why do you think this is not a bug?
What is expected about the behavior "changed outside" or
the behavior of saying that the "original value" is something
different from the original value?
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, (continued)
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Noam Postavsky, 2016/07/09
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Eli Zaretskii, 2016/07/09
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Noam Postavsky, 2016/07/09
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Eli Zaretskii, 2016/07/09
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Drew Adams, 2016/07/09
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Drew Adams, 2016/07/09
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Drew Adams, 2016/07/10
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, npostavs, 2016/07/11
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Eli Zaretskii, 2016/07/12
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Drew Adams, 2016/07/09
bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results,
Drew Adams <=
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Eli Zaretskii, 2016/07/09
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Drew Adams, 2016/07/09
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Eli Zaretskii, 2016/07/09
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, npostavs, 2016/07/09
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Eli Zaretskii, 2016/07/10
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Drew Adams, 2016/07/10
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Eli Zaretskii, 2016/07/11
bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Drew Adams, 2016/07/10
bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Eli Zaretskii, 2016/07/11
bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Drew Adams, 2016/07/11