unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 'Emacs-Devel' <emacs-devel@gnu.org>
Subject: RE: FW: Minibuf menu when minibuffer is standalone
Date: Tue, 11 Mar 2008 15:11:01 -0800	[thread overview]
Message-ID: <004001c883cd$2d0955e0$0600a8c0@us.oracle.com> (raw)
In-Reply-To: <jwvve3tgeb5.fsf-monnier+emacs@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2748 bytes --]

> >> Consider as a possible enhancement somehow making the Minibuf 
> >> menu-bar menu available also when the minibuffer is in a
> >> standalone frame (frame parameter minibuffer has value `only').
> >> 
> >> Because the minibuffer maps are local maps, when you have a
> >> standalone minibuffer frame, which has no menu-bar, the Minibuf
> >> menu-bar menu is not available anywhere. (The other frames do
> >> not have minibuffers, and their buffers do not have the
> >> minibuffer map as local map.)
> >> 
> >> Perhaps menu Minibuf could somehow be made to appear in all 
> >> frames that have a menu-bar, whenever the minibuffer is active.
> >> I'm not sure how that might be implemented, because it is good
> >> to keep the current situation of the minibuffer maps being
> >> local to the minibuffer. But if a good implementation could be
> >> found, it would be desirable to have the Minibuf menu available
> >> also for users who have a standalone minibuffer.
> 
> Actually, I'd hate such a behavior.  It's only relatively recently
> (maybe a couple years) that I discovered the minibuffer menus, where
> I tested Emacs in a non-separate-minibuffer-frame setting and 
> found the menu-bar switching just inconvenient.
> 
> I mean, really, all that menu-bar-switching for what?
> 3 miserable commands?

Any such argument can be levelled equally agains the Minibuf menu in general
- it has nothing to do with the suggestion to make the existing menu
available to people who use a standalone minibuffer.

Are you suggesting that we remove the Minibuf menu altogether? If so, then
yes, let's answer that question first. If the answer is that it should be
kept, then my question remains: Why not also make it available somehow for
those with a standalone minibuffer?

Wrt "all that menu-bar switching": Does that mean that you are also against
the dynamic changing of menus in general, or at least when they have
relatively few items?

Wrt "3 miserable commands": 1. The number of commands shouldn't be a very
important argument for keeping or tossing a menu. 2. Other applications
might add additional items to the menu. In Icicles, for example, the Minibuf
menu has all of the items in the attached screenshot. There are more than "3
miserable commands" there. And, as Lennart pointed out, menus can help you
learn what's available and what key bindings there are - it's a lot quicker
to check some things that way than consult the manual, even in Emacs.

Out of curiosity, do you use menus at all? If not, do you at least see their
value for others? I'm wondering if your response is about just the Minibuf
menu or all menus. Let's separate the concerns, please. My question is in
the context where Emacs will continue to have a Minibuf menu.


[-- Attachment #2: drew-emacs-Minibuf-menu.PNG --]
[-- Type: image/png, Size: 12185 bytes --]

      parent reply	other threads:[~2008-03-11 23:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-11 19:08 FW: Minibuf menu when minibuffer is standalone Drew Adams
2008-03-11 19:34 ` Lennart Borgman (gmail)
2008-03-11 21:10 ` Stefan Monnier
2008-03-11 21:39   ` Lennart Borgman (gmail)
2008-03-11 21:50     ` Stefan Monnier
2008-03-11 22:05       ` Lennart Borgman (gmail)
2008-03-12  1:11         ` Stefan Monnier
2008-03-13  2:01           ` Juri Linkov
2008-03-11 23:11   ` Drew Adams [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='004001c883cd$2d0955e0$0600a8c0@us.oracle.com' \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).