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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7087 in the body.
You can then email your comments to 7087 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.50;
	cannot customize default-frame-alist - it says value is nil but it is
	not
Date: Wed, 22 Sep 2010 15:15:42 -0700

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'
 

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

From: Eli Zaretskii <eliz <at> gnu.org>
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: Thu, 23 Sep 2010 10:31:26 +0200

> From: "Drew Adams" <drew.adams <at> 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?

Message #11 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: Thu, 23 Sep 2010 14:06:58 +0200

> 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

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
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: Thu, 23 Sep 2010 13:35:25 -0700

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

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.