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

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

[Drew Adams]

When the minibuffer is used the menu-bar automatically changes to
provide menus appropriate for using the minbuffer.  This is a good
thing.

However, there can be use cases for keeping the menu-bar as it was
before the minbuffer was entered.  This can be the case if the
minibuffer is used to access menu-bar menu items (using completion, for
instance).  In such contexts it can make sense for the command reading
from the minibuffer to be able to keep the menu-bar as it was, so users
can see what the menu names are.

This enhancement request is to provide that possibility in Lisp - for
example by binding a global variable.

In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor `Microsoft Corp.', version 10.0.19042
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

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

[Drew Adams]

I misstated this.  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.

Case in point -

In a Dired buffer you have these menus, in
addition to the standard File, Edit, Options,
Buffers, Tools, and Help:

 Operate
 Mark
 Regexp
 Immediate
 Subdir

Those are lost when the minibuffer is active.

In addition, the "standard" File etc. menus
can have different content depending on the
current mode.  Using the mode of the minibuffer
isn't helpful for the menu-bar, in general.

Or at least it sometimes isn't.  Hence the
request to _be able_ to keep the menu-bar as
it was before the minibuffer was entered.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Wed, 29 Dec 2021 22:22:02 +0000
> 
> I misstated this.  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.

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

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.

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

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

[Drew Adams]

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

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "52874@debbugs.gnu.org" <52874@debbugs.gnu.org>
> Date: Thu, 30 Dec 2021 15:43:20 +0000
> 
> > 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.

I've seen it.

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

Then that particular command can add  the menu items it wants back.
There's no need to change how Emacs works because one specific command
wants it to work differently.

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

You are arguing for a general solution, so I'm pointing out a general
problem with that.

> And the only menu added is Minibuf.

Not in general.  Ever major and minor mode can add something to
the menu bar's top-level menus.

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

There's nothing special with the behavior when you enter the
minibuffer.  It is just a consequence of changing the major mode.

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

[Drew Adams]

> There's nothing special with the behavior when you enter the
> minibuffer.  It is just a consequence of changing the major mode.

Yes, I know.  You apparently haven't understood
what the request is, or why it's requested.
So be it.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "52874@debbugs.gnu.org" <52874@debbugs.gnu.org>
> Date: Thu, 30 Dec 2021 17:59:53 +0000
> Accept-Language: en-US
> 
> > There's nothing special with the behavior when you enter the
> > minibuffer.  It is just a consequence of changing the major mode.
> 
> Yes, I know.  You apparently haven't understood
> what the request is, or why it's requested.

Yes, of course: anyone who disagrees with you didn't understand what
you are asking or didn't read the report.  There's no place for
disagreement in your world, only for ineptitude and lack of attention.

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

[Drew Adams]

> > > There's nothing special with the behavior when you enter the
> > > minibuffer.  It is just a consequence of changing the major mode.
> >
> > Yes, I know.  You apparently haven't understood
> > what the request is, or why it's requested.
> 
> Yes, of course: anyone who disagrees with you didn't understand what
> you are asking or didn't read the report.  There's no place for
> disagreement in your world, only for ineptitude and lack of attention.

There's no need for such aggression, Eli.

It appears to me that you haven't understood
what I requested, or why.  That could as much
be due to my inability to communicate it as
to any problem on your end.

I was hoping that the analog example of
`menu-bar-open' might clarify the (unusual)
use case.  I'm sorry it didn't.

It's about mention and use.  The command in
question uses the menus that are available
when the command is invoked.  But while you
are interactively using them you can no
longer see them on the menu-bar.  Admittedly,
such a use case is not common.

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

[Drew Adams]

BTW, I tried your suggestion of having the command
put back the menu-bar menus of the original buffer.

I found no way to do that so that menu shows while 
the command reads with `completing-read'.

I tried to do it using `minibuffer-setup-hook',
using `after-change-major-mode-hook', and using
`change-major-mode-after-body-hook', but I had no 
luck.

This would need to be done after the menu-bar gets
changed to reflect the major mode that's in effect
when the minibuffer is active.  It's that menu-bar
that I want to replace by the one present before
invoking the command.

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

[Drew Adams]

Closing this, as it's unlikely to be important
to others, and it isn't that important to me.
Thx.