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

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

[Drew Adams]

emacs -Q
 
(defcustom foo '(("foo" (f1 f2) f3) ("bar" (b1 b2) b3))
  "..."
  :type '(repeat
   (cons
    (choice :tag "a" string symbol)
    (choice
     (const :tag "b" nil)
     (function :tag "c")
     (list :tag "d"
    (repeat (function :tag "e"))
    (choice
     (const :tag "f" nil)
     (function :tag "g")))))))
 
(defcustom toto (copy-sequence foo)
  "..."
  :type '(repeat
   (cons
    (choice :tag "r" string symbol)
    (choice
     (const :tag "s" nil)
     (function :tag "t")
     (list :tag "u"
    (repeat (function :tag "v"))
    (choice
     (const :tag "w" nil)
     (function :tag "x")))))))
 
(defun f1 ())
(defun f2 ())
(defun f3 ())
 
(defun b1 ())
(defun b2 ())
(defun b3 ())
 
Then M-x customize-option foo
 
Insert another alist element, then set the value for the session, so
foo's value now has 3 alist elements. Option toto's value is like
foo's, but it is missing the first alist element (the new one).
 
Put point on toto's defcustom and do `C-M-x'. The value is not updated
to be a copy of foo's current value. The value looks like it hasn't
changed.
 
AFAIK, there are no side effects going on here. And if you explicitly
do (setq toto (copy-sequence foo)), then it of course does get updated
to reflect the latest foo value.
 
Seems like a bug. There's no doubt a simpler test case, but I have this
ready-to-hand and don't feel like paring it down.
 
 
 
In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600)
 of 2009-07-29 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4)'
 

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

[npostavs]

tags 4755 unreproducible
quit

"Drew Adams" <drew.adams@oracle.com> writes:

> emacs -Q
>  
> (defcustom foo '(("foo" (f1 f2) f3) ("bar" (b1 b2) b3))
>   "..."
>   :type '(repeat
>    (cons
>     (choice :tag "a" string symbol)
>     (choice
>      (const :tag "b" nil)
>      (function :tag "c")
>      (list :tag "d"
>     (repeat (function :tag "e"))
>     (choice
>      (const :tag "f" nil)
>      (function :tag "g")))))))
>  
> (defcustom toto (copy-sequence foo)
>   "..."
>   :type '(repeat
>    (cons
>     (choice :tag "r" string symbol)
>     (choice
>      (const :tag "s" nil)
>      (function :tag "t")
>      (list :tag "u"
>     (repeat (function :tag "v"))
>     (choice
>      (const :tag "w" nil)
>      (function :tag "x")))))))
>  
> (defun f1 ())
> (defun f2 ())
> (defun f3 ())
>  
> (defun b1 ())
> (defun b2 ())
> (defun b3 ())
>  
> Then M-x customize-option foo
>  
> Insert another alist element, then set the value for the session, so
> foo's value now has 3 alist elements. Option toto's value is like
> foo's, but it is missing the first alist element (the new one).
>  
> Put point on toto's defcustom and do `C-M-x'. The value is not updated
> to be a copy of foo's current value. The value looks like it hasn't
> changed.
>  
> AFAIK, there are no side effects going on here. And if you explicitly
> do (setq toto (copy-sequence foo)), then it of course does get updated
> to reflect the latest foo value.
>  
> Seems like a bug. There's no doubt a simpler test case, but I have this
> ready-to-hand and don't feel like paring it down.
>  
>  
>  
> In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600)
>  of 2009-07-29 on SOFT-MJASON
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (4.4)'
>  

Can't reproduce on Emacs 23.4, perhaps it was fixed?

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

[Drew Adams]

> tags 4755 unreproducible
> quit

> Can't reproduce on Emacs 23.4, perhaps it was fixed?

I just reproduced it using Emacs 25, from emacs -Q. Here's
some of the proof of a problem:

toto's value is shown below.

Documentation:
...

You can customize this variable.

Value: (("foo" (f1 f2) f3) ("bar" (b1 b2) b3))
Original value was 
(("foo"
  (f1 f2)
  f3)
 ("bar"
  (b1 b2)
  b3)
 ("toto"
  (f1 f2 f3)
  nil))

`foo', not `toto' was customized, and the Value shown
here is correct. But the "Original value" is incorrect.
The "Original value" shown is the new, current value
of `foo'.  `toto' never had, as still does not have,
that "Original value".

For the above, I did not even get to the part of the
recipe that calls for using `C-M-x' on the `toto'
defcustom.  All I did was customize `foo' and set it
for the session.

Then, doing `C-M-x' does correctly show `toto' as
having the same value as `foo'.

So if you prefer, yes, the bug as reported seems to be
fixed.  But there is another bug, shown above:
customizing `foo' changes the "Original value" part
of the output of `C-h v' for `toto'.

Something is still amiss in the state of Denmark...

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

[Noam Postavsky]

On Tue, Jul 5, 2016 at 10:30 AM, Drew Adams <drew.adams@oracle.com> wrote:
> `foo', not `toto' was customized, and the Value shown
> here is correct. But the "Original value" is incorrect.
> The "Original value" shown is the new, current value
> of `foo'.  `toto' never had, as still does not have,
> that "Original value".

Ah, but this appears to be expected behaviour:

    (defcustom SYMBOL STANDARD DOC &rest ARGS)

    [...]
    STANDARD is an expression specifying the variable's standard
    value.  It should not be quoted.  It is evaluated once by
    `defcustom', and the value is assigned to SYMBOL if the variable
    is unbound.  The expression itself is also stored, so that
    Customize can re-evaluate it later to get the standard value.
    DOC is the variable documentation.

Compare what happens with:

(defcustom time (current-time)
  "the time"
  :type '(list integer))

So perhaps the thing to be fixed is that describe-variable should say
"Standard value" rather than "Original value".

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

[Drew Adams]

> > `foo', not `toto' was customized, and the Value shown
> > here is correct. But the "Original value" is incorrect.
> > The "Original value" shown is the new, current value
> > of `foo'.  `toto' never had, as still does not have,
> > that "Original value".
> 
> Ah, but this appears to be expected behaviour:
> 
>     (defcustom SYMBOL STANDARD DOC &rest ARGS)
> 
>     [...]
>     STANDARD is an expression specifying the variable's standard
>     value.  It should not be quoted.  It is evaluated once by
>     `defcustom', and the value is assigned to SYMBOL if the variable
>     is unbound.  The expression itself is also stored, so that
>     Customize can re-evaluate it later to get the standard value.
>     DOC is the variable documentation.
> 
> Compare what happens with:
> 
> (defcustom time (current-time)
>   "the time"
>   :type '(list integer))

I don't see why any of that indicates that what I described
is "expected".  But it does seem to confirm that there are
problems.

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.

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'?

Also, `M-x customize-option time' shows this, which seems
wrong.  Seems like `C-h v' is taken as changing the value
outside customize?

 State : CHANGED outside Customize. (mismatch)

I have not reevaluated the defcustom at all.  All I did
was evaluate it once and then use `C-h v time' a few times.

Anyway, there is a type mismatch.  You should have used
:type '(list integer integer integer integer).

But even so, it does not seem right that a type mismatch
should mess things up so much.

For example, the State menu shows the item `Show Saved
Lisp Expression' _disabled_.  And it shows item `Revert
This Session's Customization', even though I have done no
customization.  And if I choose `Revert...' there is no
change in the menu.

I'm guessing that these problems arise because there is
a type mismatch.  But they still shouldn't manifest this
way, I think.

Seems buggy.  I did this with emacs -Q, with this Emacs 25
build:

In GNU Emacs 25.1.50.1 (i686-pc-mingw32)
 of 2015-12-10
Repository revision: 6148555ee5a3d0139ae517803718b3e0357933c7
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --prefix=/c/Devel/emacs/snapshot/trunk --enable-checking=yes
 --enable-check-lisp-object-type --without-compress-install 'CFLAGS=-Og
 -ggdb3' LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''

Seems like we've stumbled on more than one bug here?

Correcting the :type and trying again, with a new variable
named `atime', I still see the State as CHANGED outside Customize.

And again, that's just by evaluating the defcustom once and
doing `C-h v' a couple times.

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

[Noam Postavsky]

On Tue, Jul 5, 2016 at 1:30 PM, Drew Adams <drew.adams@oracle.com> wrote:
> 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.

>
> 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).

> 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.

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

[Drew Adams]

> > 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.

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

[npostavs]

close 4755
quit

Drew Adams <drew.adams@oracle.com> writes:

> 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'.

Yes, that's what I meant.  Anyway, I'm opening a new bug for this, since
it's not the same as the original, and from experience, I can say that
having multiple bugs per report is confusing.

See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23926