emacs-devel
[Top][All Lists]
Advanced

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

Re: C-l while in menu?


From: Ben Wing
Subject: Re: C-l while in menu?
Date: Wed, 24 Apr 2002 03:44:59 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2



Kim F. Storm wrote:
Miles Bader <address@hidden> writes:

Ben Wing <address@hidden> writes:
the fact is that things work quite well when you have only a meta key.
e.g. meta+letter is an accelerator only when such a menu exists;
otherwise, you get the regular binding -- and even then you can
retrieve the shadowed binding with shift+meta+letter.
Do people really like this?  It sounds astonishly annoying to have
random meta keys stolen by the menus, especially since emacs has many
useful and common commands on M-letter keys. E.g., doesn't the `File'
menu steal `M-f', the `Buffers' menu `M-b', etc.?

I am skeptical ...

So am I.

I rarely use the menus, so I definitely don't want any accellerator
keys to steal *ANY* of the M- key bindings which are hardwired into my
spine after +15 years of emacs usage...

On the other hand, I think many new users would expect that M-f would
open the File menu, and since he doesn't already know that M-f runs
forward-word, he'll probably never be bothered with having to use S-M-f
to invoke that command.

Personally, I wouldn't mind if I could use S-M-f to open the File menu
- but if I'm in message mode, I'd much rather prefer if it opened the
Field menu...

So, what's the right approach here?

Well, at least make the accellerator modifier(s) configurable!!!

Default could be 'meta or 'alt or '(shift meta) or nil -- depending
on whether we want to help new users (annoying old-timers), or vice versa.

the general principle i'm acting on is that we should cater to what's standard and to the new users; old timers know how to customize and turn off annoying features, new users don't know how to get back the features they want, and will probably think the program is just broken.



BTW, I think most of this logic be implemented in lisp if we
just had two built-in functions like

(menu-bar-item-matching-p key) -> returns t if menu starting with KEY exists
(open-menu-bar-item-matching key) -> opens that menu.

Then, in a menu-accell minor mode, we could have code and bindings like

(defun menu-accell-check-item ()
(menu-bar-item-matching-p (this-command-key))

(defun menu-accell-open-item ()
(interactive)
(open-menu-bar-item-matching (this-command-key)))

(defcustom menu-accell-modifiers '(meta))

... for KEY in ?a to ?z do ...
(define-key menu-accell-map
(vector (append menu-accell-modifiers (list key))) ;; eg M-f
'(menu-item "accell" menu-accell-open-item
:filter menu-accell-check-item))


If we want another accellerator modifier, simply clear the menu-accell-map
and rebuild it using the new accellerator modifier. This can be done
automatically in the :set action of menu-accell-modifiers.

Just an idea...



reply via email to

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