[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing
From: |
npostavs |
Subject: |
bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results |
Date: |
Sat, 09 Jul 2016 07:54:58 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.93 (gnu/linux) |
retitle 23926 defcustom with STANDARD=<non-constant-expression> gives confusing
results
quit
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Fri, 8 Jul 2016 23:11:02 -0400
>>
>> A trivial example:
>>
>> (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.
Yeah, it seems expected because you're familiar with the code. But it
causes Emacs to claim the "original" value is different from what it
originally was, which seems nonsensical.
I wonder why Emacs saves only the original expression and not the
actual original value?
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Noam Postavsky, 2016/07/08
- 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 <=
- 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, 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