[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 17:03:39 +0300 |
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sat, 9 Jul 2016 09:48:18 -0400
> Cc: 23926@debbugs.gnu.org
>
> On Sat, Jul 9, 2016 at 9:14 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > For now, we just compare to the
> > previous recorded value (computed at dump time, I presume).
>
> Dump time? This doesn't apply to non-preloaded libraries though, right?
Right.
> > The question is, given the above, do we need to actually do anything
> > with this report, except close it?
>
> Either really save the original value, or don't call it the "original
> value". We can't use "default value" because that's already used for
> the non-buffer local value, unfortunately. I think "standard value"
> could work, though Drew said it was unclear.
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.
- 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, 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, 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