bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#52874: [External] : Re: bug#52874: 26.3; Be able to keep current men


From: Eli Zaretskii
Subject: bug#52874: [External] : Re: bug#52874: 26.3; Be able to keep current menu-bar menus when minibuffer is used
Date: Thu, 30 Dec 2021 18:42:18 +0200

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]