GNU bug report logs -
#52874
26.3; Be able to keep current menu-bar menus when minibuffer is used
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Wed, 29 Dec 2021 16:38:02 UTC
Severity: wishlist
Found in version 26.3
Done: Drew Adams <drew.adams <at> oracle.com>
Bug is archived. No further changes may be made.
Full log
Message #14 received at 52874 <at> debbugs.gnu.org (full text, mbox):
> > 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
This bug report was last modified 3 years and 144 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.