* bug#52874: 26.3; Be able to keep current menu-bar menus when minibuffer is used @ 2021-12-29 16:37 Drew Adams 2021-12-29 22:22 ` Drew Adams 0 siblings, 1 reply; 10+ messages in thread From: Drew Adams @ 2021-12-29 16:37 UTC (permalink / raw) To: 52874 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'' ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52874: 26.3; Be able to keep current menu-bar menus when minibuffer is used 2021-12-29 16:37 bug#52874: 26.3; Be able to keep current menu-bar menus when minibuffer is used Drew Adams @ 2021-12-29 22:22 ` Drew Adams 2021-12-30 5:57 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Drew Adams @ 2021-12-29 22:22 UTC (permalink / raw) To: Drew Adams, 52874@debbugs.gnu.org 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52874: 26.3; Be able to keep current menu-bar menus when minibuffer is used 2021-12-29 22:22 ` Drew Adams @ 2021-12-30 5:57 ` Eli Zaretskii 2021-12-30 15:43 ` bug#52874: [External] : " Drew Adams 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2021-12-30 5:57 UTC (permalink / raw) To: Drew Adams; +Cc: 52874 > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52874: [External] : Re: bug#52874: 26.3; Be able to keep current menu-bar menus when minibuffer is used 2021-12-30 5:57 ` Eli Zaretskii @ 2021-12-30 15:43 ` Drew Adams 2021-12-30 16:42 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Drew Adams @ 2021-12-30 15:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 52874@debbugs.gnu.org > > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52874: [External] : Re: bug#52874: 26.3; Be able to keep current menu-bar menus when minibuffer is used 2021-12-30 15:43 ` bug#52874: [External] : " Drew Adams @ 2021-12-30 16:42 ` Eli Zaretskii 2021-12-30 17:59 ` Drew Adams 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2021-12-30 16:42 UTC (permalink / raw) To: Drew Adams; +Cc: 52874 > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52874: [External] : Re: bug#52874: 26.3; Be able to keep current menu-bar menus when minibuffer is used 2021-12-30 16:42 ` Eli Zaretskii @ 2021-12-30 17:59 ` Drew Adams 2021-12-30 18:11 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Drew Adams @ 2021-12-30 17:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 52874@debbugs.gnu.org > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52874: [External] : Re: bug#52874: 26.3; Be able to keep current menu-bar menus when minibuffer is used 2021-12-30 17:59 ` Drew Adams @ 2021-12-30 18:11 ` Eli Zaretskii 2021-12-30 19:05 ` Drew Adams 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2021-12-30 18:11 UTC (permalink / raw) To: Drew Adams; +Cc: 52874 > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52874: [External] : Re: bug#52874: 26.3; Be able to keep current menu-bar menus when minibuffer is used 2021-12-30 18:11 ` Eli Zaretskii @ 2021-12-30 19:05 ` Drew Adams 2021-12-30 20:37 ` Drew Adams 0 siblings, 1 reply; 10+ messages in thread From: Drew Adams @ 2021-12-30 19:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 52874@debbugs.gnu.org > > > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52874: [External] : Re: bug#52874: 26.3; Be able to keep current menu-bar menus when minibuffer is used 2021-12-30 19:05 ` Drew Adams @ 2021-12-30 20:37 ` Drew Adams 2021-12-31 16:01 ` Drew Adams 0 siblings, 1 reply; 10+ messages in thread From: Drew Adams @ 2021-12-30 20:37 UTC (permalink / raw) To: Drew Adams, Eli Zaretskii; +Cc: 52874@debbugs.gnu.org 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52874: [External] : Re: bug#52874: 26.3; Be able to keep current menu-bar menus when minibuffer is used 2021-12-30 20:37 ` Drew Adams @ 2021-12-31 16:01 ` Drew Adams 0 siblings, 0 replies; 10+ messages in thread From: Drew Adams @ 2021-12-31 16:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 52874@debbugs.gnu.org Closing this, as it's unlikely to be important to others, and it isn't that important to me. Thx. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-12-31 16:01 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-12-29 16:37 bug#52874: 26.3; Be able to keep current menu-bar menus when minibuffer is used Drew Adams 2021-12-29 22:22 ` Drew Adams 2021-12-30 5:57 ` Eli Zaretskii 2021-12-30 15:43 ` bug#52874: [External] : " Drew Adams 2021-12-30 16:42 ` Eli Zaretskii 2021-12-30 17:59 ` Drew Adams 2021-12-30 18:11 ` Eli Zaretskii 2021-12-30 19:05 ` Drew Adams 2021-12-30 20:37 ` Drew Adams 2021-12-31 16:01 ` Drew Adams
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).