unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#7087: 24.0.50; cannot customize default-frame-alist - it says value is nil but it is not
@ 2010-09-22 22:15 Drew Adams
  2010-09-23  8:31 ` Eli Zaretskii
  2010-09-23 12:06 ` martin rudalics
  0 siblings, 2 replies; 5+ messages in thread
From: Drew Adams @ 2010-09-22 22:15 UTC (permalink / raw)
  To: 7087

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'
 






^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#7087: 24.0.50; cannot customize default-frame-alist - it says value is nil but it is not
  2010-09-22 22:15 bug#7087: 24.0.50; cannot customize default-frame-alist - it says value is nil but it is not Drew Adams
@ 2010-09-23  8:31 ` Eli Zaretskii
  2010-09-23 12:06 ` martin rudalics
  1 sibling, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2010-09-23  8:31 UTC (permalink / raw)
  To: Drew Adams; +Cc: 7087

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





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#7087: 24.0.50; cannot customize default-frame-alist - it says value is nil but it is not
  2010-09-22 22:15 bug#7087: 24.0.50; cannot customize default-frame-alist - it says value is nil but it is not Drew Adams
  2010-09-23  8:31 ` Eli Zaretskii
@ 2010-09-23 12:06 ` martin rudalics
  2010-09-23 20:35   ` Drew Adams
  1 sibling, 1 reply; 5+ messages in thread
From: martin rudalics @ 2010-09-23 12:06 UTC (permalink / raw)
  To: Drew Adams; +Cc: 7087

 > 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





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#7087: 24.0.50; cannot customize default-frame-alist - it says value is nil but it is not
  2010-09-23 12:06 ` martin rudalics
@ 2010-09-23 20:35   ` Drew Adams
  2010-09-24  5:51     ` martin rudalics
  0 siblings, 1 reply; 5+ messages in thread
From: Drew Adams @ 2010-09-23 20:35 UTC (permalink / raw)
  To: 'martin rudalics'; +Cc: 7087

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






^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#7087: 24.0.50; cannot customize default-frame-alist - it says value is nil but it is not
  2010-09-23 20:35   ` Drew Adams
@ 2010-09-24  5:51     ` martin rudalics
  0 siblings, 0 replies; 5+ messages in thread
From: martin rudalics @ 2010-09-24  5:51 UTC (permalink / raw)
  To: Drew Adams; +Cc: 7087

 > 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





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-09-24  5:51 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-22 22:15 bug#7087: 24.0.50; cannot customize default-frame-alist - it says value is nil but it is not Drew Adams
2010-09-23  8:31 ` Eli Zaretskii
2010-09-23 12:06 ` martin rudalics
2010-09-23 20:35   ` Drew Adams
2010-09-24  5:51     ` martin rudalics

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).