bug#52874: [External] : Re: bug#52874: 26.3; Be able to keep current menu-bar menus when minibuffer is used

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

> > The problem is that when the
> > minibuffer is active, the menu-bar menus are no
> > longer those for what was the current buffer
> > before it was active.
> >
> > The problem is not the _addition_ of a Minibuf
> > menu to the menu-bar.  The problem is that the
> > menu-bar menus are changed to be those for the
> > new current buffer, which is the minibuffer.
> >
> > It should be enough that menu Minibuf is added,
> > and so available.  There's little sense in
> > changing the other menus to those for a
> > relatively plain  buffer such as the minibuffer.
> 
> It _is_ added, after removing the parts that were
> specific to the mode of the original buffer.  The
> "constant" parts of the menu bar are kept.

Yes, that's what I said: Minibuf is added and
the non-"constant" menus are removed.

It's the removal of those non-constant menus
that I'm asking to _be able_ to prevent from
happening.

> I still don't understand what kind of problem this causes.  In your
> Dired example, the Dired-specific menu items are not useful in the
> minibuffer; in fact, using those menu items could get  the user in
> trouble (recursive minibuffers and all that).

Please see the original bug report.

They _are_ useful for a command that uses the
minibuffer to browse and use the menu-bar menus.

In such a context it's useful to see what the
menu-bar menus are for the mode in question,
because that's the mode the command was invoked
in.

> On the practical side, adding menu items could easily overflow the
> one screen line allocated to the menu bar, after which the behavior
> becomes ugly and toolkit-dependent.

That's a general problem.  It's not particular
to this context.  And the only menu added is
Minibuf.

And if you really think that's a problem then
the ability to keep the menu-bar as it was when
the minibuffer is entered could forego adding
menu Minibuf to the menu-bar.  Not a problem.

This is about _allowing_ (e.g. by binding a var)
code to keep the menu-bar as it was when the
minibuffer was entered.  It's not about imposing
such behavior.  Allow.  Temporarily.

> So I think you suggestion, if accepted, would be a step in the wrong
> direction.

Again, it would be done only by choice, e.g. for
a given command.

The point is that a command whose purpose is to
do something with the menu-bar menus is about the
menus that are active when (i.e., just as/before)
that command is invoked.  Its entire behavior is
about those menus - _not_ the Minibuf menu plus
"the constant parts of the menu-bar".

It's about a command that, like `menu-bar-open',
uses the menu-bar as it was before that command
is invoked.

When `menu-bar-open' is invoked, the menu-bar
menus aren't changed (the minibuffer isn't used).

A command that navigates the menus using the
minibuffer should, likewise, be able to prevent
the menu-bar menus from changing.  That's all.

For my particular use case, such a command is
`lacarte-execute-menu-command'.  I'd like to be
able to have it bind a global variable that
would prevent the menu-bar from changing as
long as that binding is in effect.
___

https://www.emacswiki.org/emacs/download/lacarte.el