Subject: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil)

From: martin rudalics <[email-masked]>
Date: Mon, 29 Nov 2010 21:14:27 +0100

> The frame we are creating is not yet ready, and is certainly not yet
 > the selected frame!  Isn't that a bug? shouldn't we use
 > menu-updating-frame instead of nil, in the above call to
 > frame-parameter?

I think so.  Hopefully `menu-updating-frame' has the correct parameters
in place.

 > Sorry, I don't follow: are you saying that we must not evaluate Lisp
 > code inside `define-key', or are you saying something else?

I thought about wrapping the Lisp code so that the call fails more
gracefully.  Crashing seems a bit too harsh to me, at least for such
a trivial reason.

 >> (2) The menu-bar define-key operations to toggle `menu-bar-mode' and
 >>      `tool-bar-mode' do not take into account that the values of the
 >>      respective frame parameter can be nil.
 >
 > As you see above, this happens for the minibuffer frame.  Can you
 > explain how we get `(menu-bar-lines)' instead of having the usual
 > `(menu-bar-lines . 1)' or `(menu-bar-lines . 0)' in the parameters
 > alist of the minibuffer frame?  Is that normal, or is that another
 > bug?

IIRC it's somewhere documented that `menu-bar-lines' and
`tool-bar-lines' can be nil.  And a user can always remove a parameter
completely so any frame parameter can be nil.

 >> (3) Frame parameters of `menu-bar-lines' and actual appearance of a
 >>      menubar are inconsistent for minibuffer-only frames.

Though unrelated this strikes me as the strangest bug of them all.  It
means that we can't rely on the actual value of a frame parameter even
if it's non-nil.

martin