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

[martin rudalics]

> 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