[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Drew Adams
Subject: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil)
Date: Tue, 30 Nov 2010 09:57:20 -0800

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

Why by design?  I mean why must that be the design?  No menu-bar by default, I
could understand.

But I can see that someone might well want a menu-bar for a minibuffer
standalone frame.  After all, there is a menu-bar menu, `Minibuf', which is
missing altogether when you use a standalone minibuffer frame.  I've asked in
the past that the `Minibuf' menu be made available (or it at least be possible
to make it available) even when you use a standalone minibuffer frame.

I think `menu-bar-lines' and even `tool-bar-lines' should be respected by a
minibuffer frame.  Why preclude users from having these if they find some use
for them in some context?  What reason can we have for a design that _prevents_
a minibuffer frame from using these?  Sounds short-sighted, to me.

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.

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

I think so too, but my recollection of this is faint and probably faulty.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]