bug#7087: 24.0.50; cannot customize default-frame-alist - it says value is nil but it is not

bug#7087: 24.0.50; cannot customize default-frame-alist - it says value is nil but it is not

[Drew Adams]

This is not starting from emacs -Q, but the setup is too long to
describe here.
 
In Emacs 23.2 and previous releases, there is no problem.
 
In this Emacs 24 build, M-x customize-option default-frame-alist gives a
Customize buffer that shows the value of the option as nil and says
"this option has been changed outside the customize buffer. (mismatch)".
However, C-h v default-frame-alist shows it has a non-nil value:
 
((foreground-color . "Black")
 (background-color . "LightBlue")
 (font . "-*-Lucida Console-normal-r-*-*-14-112-96-96-c-*-iso8859-1")
 (mouse-color . "Red")
 (cursor-color . "Red")
 (cursor-type . bar)
 (menu-bar-lines . 1)
 (top . 0)
 (left . 0)
 (width . 80)
 (height . 35)
 (minibuffer)
 (user-position . t)
 (vertical-scroll-bars . right)
 (icon-type)
 nil
 (left-fringe . 0)
 (right-fringe . 0)
 (fringe . 0))
 
Clearly there is a mismatch, not between the value and what the option
spec should be, but between what Customize thinks the value is and what
the value is in fact.  And even if the option value were nil, I don't
think that would signify a mismatch.  Something is very wrong here.
 

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-09-20 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'
 

bug#7087: 24.0.50; cannot customize default-frame-alist - it says value is nil but it is not

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Wed, 22 Sep 2010 15:15:42 -0700
> Cc: 
> 
> This is not starting from emacs -Q, but the setup is too long to
> describe here.

But it's a crucial detail, because in "emacs -Q" the problem does not
exist.  Could you please provide a minimal recipe that reproduces this
problem starting with "emacs -Q", or at least some insight into the
setup which causes that?

bug#7087: 24.0.50; cannot customize default-frame-alist - it says value is nil but it is not

[martin rudalics]

 > In this Emacs 24 build, M-x customize-option default-frame-alist gives a
 > Customize buffer that shows the value of the option as nil and says
 > "this option has been changed outside the customize buffer. (mismatch)".
 > However, C-h v default-frame-alist shows it has a non-nil value:
 >
 > ((foreground-color . "Black")
...
 >  (icon-type)
 >  nil
    ^^^
`default-frame-alist' has the customization type

	       (repeat (cons :format "%v"
			     (symbol :tag "Parameter")
			     (sexp :tag "Value"))))

so obviously this "nil" here will cause a mismatch.

 >  (left-fringe . 0)
 >  (right-fringe . 0)
 >  (fringe . 0))
 >
 > Clearly there is a mismatch, not between the value and what the option
 > spec should be, but between what Customize thinks the value is and what
 > the value is in fact.  And even if the option value were nil, I don't
 > think that would signify a mismatch.  Something is very wrong here.

Indeed.  You just have to find the culprit ;-)

martin

bug#7087: 24.0.50; cannot customize default-frame-alist - it says value is nil but it is not

[Drew Adams]

>  > In this Emacs 24 build, M-x customize-option 
>  > default-frame-alist gives a Customize buffer that shows the
>  > value of the option as nil and says
>  > "this option has been changed outside the customize 
>  > buffer. (mismatch)". However, C-h v default-frame-alist shows
>  > it has a non-nil value:
>  >
>  > ((foreground-color . "Black")
> ...
>  >  (icon-type)
>  >  nil
>     ^^^

Good catch. I didn't notice that. Dunno how that happened. 

However, if the value does become something like that for some reason, then the
displayed value should be the complete sexp that is the value, not just one
little part of it. So there is apparently a bug present in any case - probably
in the customize code.

> `default-frame-alist' has the customization type
> 
> 	       (repeat (cons :format "%v"
> 			     (symbol :tag "Parameter")
> 			     (sexp :tag "Value"))))
> 
> so obviously this "nil" here will cause a mismatch.

Yes, indeed. Again, dunno how the nil value got there. Probably something that
happened during the session. Perhaps there is a bug elsewhere that introduced
that.

Note though that the nil entry did not seem to in any way interfere with the
use/behavior of `default-frame-alist'.  And that makes sense.

FWIW, I've checked all of my own code to be sure that the nil alist entry could
not have come from it.  In all cases it uses a cons.  I did not check all other
3rd-party code I might load, but if I had to guess I'd guess that this came
somehow from the vanilla Emacs 24 code, mainly because I've never come across
this before.

Anyway, to follow up more -

I cannot reproduce the problem. In subsequent sessions I do not see it.  So we
can either close this or keep it as info in case we later learn of other cases
where a nil entry gets introduced.  For the moment I have no idea how that
happened, unfortunately, and I never saw it previously.  I should have tried in
a new session before posting the bug, and I should have noticed the nil entry.
But at least now we know to keep our eyes out for something that might introduce
a nil entry.  Thx.

bug#7087: 24.0.50; cannot customize default-frame-alist - it says value is nil but it is not

[martin rudalics]

 > However, if the value does become something like that for some reason, then the
 > displayed value should be the complete sexp that is the value, not just one
 > little part of it. So there is apparently a bug present in any case - probably
 > in the customize code.

Not here.  If I evaluate

(custom-set-variables
  '(default-frame-alist
     (quote
      ((foreground-color . "Black")
       (background-color . "LightBlue")
       ...

and do customize it I get "SAVED and set. (mismatch)" showing the whole
sexp in my customization buffer.

 > Yes, indeed. Again, dunno how the nil value got there. Probably something that
 > happened during the session. Perhaps there is a bug elsewhere that introduced
 > that.

Do write a function for your `post-command-hook' that checks whether a nil
value was added by the last command and run it for a while.

 > Note though that the nil entry did not seem to in any way interfere with the
 > use/behavior of `default-frame-alist'.  And that makes sense.

Why should it?  It's based on something like `assq' and we know that it
does

   Return non-nil if KEY is `eq' to the car of an element of LIST.
   The value is actually the first element of LIST whose car is KEY.
   Elements of LIST that are not conses are ignored.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 > FWIW, I've checked all of my own code to be sure that the nil alist entry could
 > not have come from it.  In all cases it uses a cons.  I did not check all other
 > 3rd-party code I might load, but if I had to guess I'd guess that this came
 > somehow from the vanilla Emacs 24 code, mainly because I've never come across
 > this before.

That's why I asked you to check this in the first place ;-)

Maybe an error condition was raised and the handler returned nil instead
of a cons.

martin