bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode'

bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode'

[Drew Adams]

emacs -Q
 
(setq special-display-frame-alist '((menu-bar-lines . 1))
      special-display-regexps     '("[ ]?[*][^*]+[*]"))
(menu-bar-mode 0)
(describe-variable 'menu-bar-mode)
 
You will see that:
 
* Buffer *Help* is displayed in its own frame.
* It says that menu-bar-mode is nil (which it is).
* The frame has a menu bar.
 
I'm not sure what should be done about this, but it is confusing, at the
least.  When the mode is disabled the menu bar is (generally) not
supposed to be present.  Command `menu-bar-mode' "applies to all frames
that exist and frames to be created in the future."  That strong
statement certainly does not match not the behavior in this case.
 
Of course, someone will argue, correctly, that when frame *Help* is
created that is done with an explicit `menu-bar-lines' setting, which
should override the mode behavior.  That's why I say that I'm not sure
what, if anything, should be done about this.  But the behavior is a bit
confusing.
 
I don't have any great suggestion.  Perhaps something more could be done
wrt the doc, at least.  For example, the doc string of the mode command
could perhaps mention the frame parameter, and vice versa, explaining
that the mode is overridden by the frame parameter.  The doc for
`menu-bar-mode' should perhaps not claim so strongly that it affects
all future frames, since that is clearly not so.
 
 
FYI -
 
This came up because I received a bug report that actually had to do
with the VERY OLD bug that trying to enlarge a frame with a wide menu
bar actually shrinks the frame (horizontally, vertically).
 
Suspecting that old bug, I tried to get a repro recipe.  The user turned
off menu-bar-mode as shown above, but the symptom persisted.  The user
didn't tell me that a menu bar was actually present, so it took a while
to figure out what the problem really was.
 
That OLD bug has never been fixed, though Emacs Dev has expressed a will
to fix it at various times.
 
Here are some references to this old bug:
 
1. Bug #456.
 
2. emacs-devel thread in 2006-06 and 2007-07: "frame parameter
   menu-bar-lines changes height of frame".
 
There were also older discussions than that, but I don't have pointers
to them.

I, for one, would like to see that old bug fixed.  I, like some others,
use keys to incrementally enlarge/shrink frames horizontally/vertically,
and whenever the frame width is less than the menu-bar width, the bug
rears its ugly head.
 
It is my wish that that longstanding bug be taken off the wishlist and
treated normally - and hopefully fixed finally.
 
In GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600)
 of 2012-09-02 on MARVIN
Bzr revision: 109861 eggert@cs.ucla.edu-20120902171035-7mzihil3xd6bjfiy
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'
 

bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode'

[Stefan Monnier]

> emacs -Q
> (setq special-display-frame-alist '((menu-bar-lines . 1))
>       special-display-regexps     '("[ ]?[*][^*]+[*]"))
> (menu-bar-mode 0)
> (describe-variable 'menu-bar-mode)
 
> You will see that:
 
> * Buffer *Help* is displayed in its own frame.
> * It says that menu-bar-mode is nil (which it is).
> * The frame has a menu bar.

The core of the problem is that menu-bar-mode is global, whereas the
presence/absence of a menu-bar is actually a frame property (and it's
important to me that it be so, because I have some frames with
a menu-bar and some without).

So `menu-bar-mode' is a lie.  One possible fix is to make menu-bar-mode
into a frame-local mode, so calling menu-bar-mode would only affect the
current frame (and maybe also the future frames) but not the other
existing frames.


        Stefan

bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode'

[Drew Adams]

> The core of the problem is that menu-bar-mode is global, whereas the
> presence/absence of a menu-bar is actually a frame property (and it's
> important to me that it be so, because I have some frames with
> a menu-bar and some without).

I agree.  The frame property should override what the mode claims - as it does.

> So `menu-bar-mode' is a lie.

That was my point.  Can we fix the doc a bit to provide a slightly clearer view
- e.g., mention that the frame parameter takes precedence?

It's OK to say that the mode affects existing and future frames, but for the
future part it should probably say "unless overridden by frame parameter
`menu-bar-lines'", or some such.  That's what I meant.

> One possible fix is to make menu-bar-mode into a frame-local mode,
> so calling menu-bar-mode would only affect the
> current frame (and maybe also the future frames) but not the other
> existing frames.

To me, that would be bad - not helpful at all.  A user should be able, as now,
to set the mode and have it (1) update all existing frames and (b) affect future
frames by setting the default behavior, i.e., unless overridden.

I personally have not needed to prevent the mode change from affecting any
particular frame.  But if you did need to have some existing frame prevent the
mode change from affecting it, then we could introduce a way to specify that.
E.g., a `menu-bar-lines' value of, say, a cons (N keep).  So a value of
(menu-bar-lines 1 keep)) would keep one line and be unaffected by mode changes.

Another possibility (orthogonal) would be to let the prefix arg of
`menu-bar-mode' do double duty, to optionally affect only the current frame.
Dunno.  But I would not want that command changed to systematically affect only
the current frame.

bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode'

[martin rudalics]

 > A user should be able, as now,
 > to set the mode and have it (1) update all existing frames

IMHO it should update a frame iff that frame has no `menu-bar-lines'
frame parameter.

 > and (b) affect future
 > frames by setting the default behavior, i.e., unless overridden.

martin

bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode'

[Drew Adams]

>  > A user should be able, as now,
>  > to set the mode and have it (1) update all existing frames
> 
> IMHO it should update a frame iff that frame has no `menu-bar-lines'
> frame parameter.'

Why?  Why shouldn't a user be ABLE to turn on/off showing the menu bar in all
existing frames?

One way or the other, we should find ways for users to alternatively easily do
that (affecting all existing frames) OR protect some frames from that toggling.

IOW, both should be possible and easy for the user to control interactively (not
just in Lisp; e.g., using a prefix arg or a different command).

>  > and (b) affect future
>  > frames by setting the default behavior, i.e., unless overridden.

bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode'

[martin rudalics]

 >> IMHO it should update a frame iff that frame has no `menu-bar-lines'
 >> frame parameter.'
 >
 > Why?  Why shouldn't a user be ABLE to turn on/off showing the menu bar in all
 > existing frames?

Because this way we'd have a consistent interface: The presence of a
frame parameter would signal "leave this frame alone".

 > One way or the other, we should find ways for users to alternatively easily do
 > that (affecting all existing frames) OR protect some frames from that toggling.

Do you have a practical use case where my proposal harms?

martin

bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode'

[Drew Adams]

>  >> IMHO it should update a frame iff that frame has no 
>  >> `menu-bar-lines' frame parameter.'
>  >
>  > Why?  Why shouldn't a user be ABLE to turn on/off showing 
>  > the menu bar in all existing frames?
> 
> Because this way we'd have a consistent interface: The presence of a
> frame parameter would signal "leave this frame alone".

That's inconsistent with the convention that absence of a frame parameter is
equivalent to its presence with a nil value.  It is similar to proposing that we
give some  special signification to the absense of a key in an alist, as opposed
to a key with value nil.

Please find another way to say "leave this frame alone".  That should not be
difficult, and it should be possible to find something that has general
applicability (i.e., any frames, any frame parameter, any function that affects
a frame parameter).

More precisely, we should be able to say "leave this frame alone for parameter
BLAH".  And even perhaps "make function FOO leave this frame alone for parameter
BLAH".  In this case, FOO is `menu-bar-mode' and BLAH is `menu-bar-lines'.

And this should be 100% orthogonal to the presence or absence of the parameter,
and 100% orthogonal to what the parameter's current value (nil or not) might be.

>  > One way or the other, we should find ways for users to 
>  > alternatively easily do that (affecting all existing
>  > frames) OR protect some frames from that toggling.
> 
> Do you have a practical use case where my proposal harms?

You are unnecessarily coupling things that do not belong together.  That's a bad
idea.  Whether a given parameter should be affected  by a given function is
logically unrelated to whether the parameter is currently present for a given
frame, and is logically unrelated to the parameter's current value for a given
frame.

bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode'

[martin rudalics]

 >> Because this way we'd have a consistent interface: The presence of a
 >> frame parameter would signal "leave this frame alone".
 >
 > That's inconsistent with the convention that absence of a frame parameter is
 > equivalent to its presence with a nil value.  It is similar to proposing that we
 > give some  special signification to the absense of a key in an alist, as opposed
 > to a key with value nil.

You're probably right.

 > You are unnecessarily coupling things that do not belong together.  That's a bad
 > idea.  Whether a given parameter should be affected  by a given function is
 > logically unrelated to whether the parameter is currently present for a given
 > frame, and is logically unrelated to the parameter's current value for a given
 > frame.

Maybe.  I never understood things like `tool-bar-lines-needed'.

martin

bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode'

[Drew Adams]

> I never understood things like `tool-bar-lines-needed'.

I never even heard of it before.

But I'm not surprised that such things exist.  The Emacs tool bar has a history
of ugly little hacks and cruftiness.

Oddly enough, BTW, `tool-bar-lines-needed' does not seem to appear anywhere in
the Emacs Lisp code!  It is defined in C for Lisp, but is not used anywhere (in
Emacs 24, at least).

bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode'

[martin rudalics]

> Oddly enough, BTW, `tool-bar-lines-needed' does not seem to appear anywhere in
> the Emacs Lisp code!  It is defined in C for Lisp, but is not used anywhere (in
> Emacs 24, at least).

I use it now for frame resizing.

martin

bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode'

[Drew Adams]

> > > I never understood things like `tool-bar-lines-needed'.
> >
> > Oddly enough, BTW, `tool-bar-lines-needed' does not seem to 
> > appear anywhere in the Emacs Lisp code!  It is defined in C
> > for Lisp, but is not used anywhere (in Emacs 24, at least).
> 
> I use it now for frame resizing.

Proof that in this case one need not understand it to make use of it! ;-)

bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode'

[Stefan Monnier]

>> Because this way we'd have a consistent interface: The presence of a
>> frame parameter would signal "leave this frame alone".
> That's inconsistent with the convention that absence of a frame
> parameter is equivalent to its presence with a nil value.  It is
> similar to proposing that we give some  special signification to the
> absense of a key in an alist, as opposed to a key with value nil.

Agreed.  That means, all frames should have a `menu-bar-lines'
parameter, set to `default' in most of them.


        Stefan

bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode'

[Drew Adams]

> >> Because this way we'd have a consistent interface: The 
> >> presence of a frame parameter would signal "leave this
> >> frame alone".
> >
> > That's inconsistent with the convention that absence of a frame
> > parameter is equivalent to its presence with a nil value.  It is
> > similar to proposing that we give some  special signification to the
> > absense of a key in an alist, as opposed to a key with value nil.
> 
> Agreed.  That means, all frames should have a `menu-bar-lines'
> parameter, set to `default' in most of them.

Sounds reasonable.  The devil might be in the details of what you want to do
with/about it.  But yes, that sounds like a start.