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.