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

[martin rudalics <rudalics@gmx.at>]

 > 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