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

[martin rudalics <rudalics@gmx.at>]

 >> The only difference I can think of is that nil stands for "this frame
 >> cannot have a menubar" and zero for "the menubar has been temporarily
 >> disabled".
 >
 > What is the difference between these two?  What does "cannot have a
 > menu bar" mean in practice?  Just wondering.

Minibuffer-only frames don't have a menubar by design.  Surprisingly
they have (menu-bar-lines . 1) here.

 >> But if not entry for `menu-bar-lines' exists, calling
 >> (frame-parameter ... 'menu-bar-lines) returns nil.
 >
 > That's not guaranteed to be true.

For the menu-bar-lines parameter it is true AFAICT.

 > You will see in the implementation
 > of frame-parameter and frame-parameters that we return values for some
 > frame parameters without ever looking at the frame's parameter alist.
 > It's true that frame-parameter actually does look in frame's parameter
 > alist when the value of menu-bar-lines is requested, but
 > frame-parameters does not, at least for TTYs.

Do you mean where it goes for the menu_bar_lines entry from the frame
structure via FRAME_MENU_BAR_LINES?  I suppose this is the only part of
the menu-bar handling code that is still correct.

 > That said, I agree that any code which is called during frame creation
 > should be able to avoid signaling an error.

I still don't get it why a condition_case can't handle such an error.

 >> Probably for using `menu-bar-lines' in a uniform manner instead of a
 >> combination of `menu-bar-mode' and `menu-bar-lines'.
 >
 > If so, this is a thing of the past, as we no longer need
 > menu-bar-mode, menu-bar-lines alone is enough, right?

Currently, menu-bar alone is enough ;-)

 > Even funnier, the ELisp manual shows an example of building a menu bar
 > with two lines, see the node "Menu Bar" there.

It used to work with Emacs' own menubars IIRC.

martin