[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing
From: |
Eli Zaretskii |
Subject: |
bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results |
Date: |
Sat, 09 Jul 2016 16:14:27 +0300 |
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sat, 9 Jul 2016 08:55:48 -0400
> Cc: 23926@debbugs.gnu.org
>
> On Sat, Jul 9, 2016 at 8:31 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: npostavs@users.sourceforge.net
> >> Cc: 23926@debbugs.gnu.org
> >> Date: Sat, 09 Jul 2016 07:54:58 -0400
> >>
> >> 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.
> >
> > It's not nonsensical, it's what actually happens, AFAIK.
>
> What actually happens is that Emacs goes back in time to change what
> the original value was?
No, that's the plan for Emacs 42. For now, we just compare to the
previous recorded value (computed at dump time, I presume).
> >> I wonder why Emacs saves only the original expression and not the
> >> actual original value?
> >
> > It does, but then it reevaluates at startup.
>
> It seems it's also reevaluated every time the variable is looked at
> with customize, or describe-variable.
Quite possibly, we reevaluate a defcustom when in doubt.
The question is, given the above, do we need to actually do anything
with this report, except close it?
- 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, 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 <=
- 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, 2016/07/09