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

Previous Next

Full log

Message #17 received at 7087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 7087 <at> debbugs.gnu.org
Subject: Re: bug#7087: 24.0.50;	cannot customize default-frame-alist - it
	says value is nil but it	is not
Date: Fri, 24 Sep 2010 07:51:38 +0200

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.