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

["Drew Adams" <drew.adams@oracle.com>]

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