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

[Drew Adams]

>  > Why by design?  I mean why must that be the design?  No 
>  > menu-bar by default, I could understand.
> 
> I doesn't have to be designed that way.  But the minibuffer window is
> special so you would have to design a minibuffer-menubar with its own
> keymap.  That would be a different design.

Minibuffer window or minibuffer frame?  The menu bar is for a frame, no?

What makes the minibuffer frame necessarily special wrt a menu-bar?

(The active minibuffer itself already has a menu-bar menu, `Minibuf', but that
is currently unavailable for the minibuffer frame, since that frame has no
menu-bar.)

>  > And I'm someone who would probably _not_ enable such 
>  > things for my own minibuffer frame.  I just don't see why
>  > we throw out the possibility.
> 
> I do.  Nobody's around to write such a thing.

Lack of resources has never prevented us from excluding the _possibility_.  Just
add it to the TODO list.

It makes perfect sense, in particular, that the `Minibuf' menu-bar menu should
be displayable when the minibuffer is active, and that is not the case now when
you use a standalone minibuffer frame.  I'd call that a bug.

But the fix for that particular bug need not necessarily be to allow a menu-bar
on the minibuffer frame.  An alternative (essentially a workaround) might be to
show the `Minibuf' menu in all frames whenever the minibuffer is active.

Aside from that (`Minibuf' menu support when you have a standalone minibuffer
frame), I think that we should add support for a menu-bar on a minibuffer frame
to the TODO list.

Whether and when particular things on the TODO list actually get done is a
question of resources.  Whether to put something on the TODO list should not be
a question of current resources.