From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ben Wing Newsgroups: gmane.emacs.devel Subject: Re: C-l while in menu? Date: Wed, 24 Apr 2002 03:44:59 -0700 Sender: emacs-devel-admin@gnu.org Message-ID: <3CC68CAB.8070008@666.com> References: <200204072343.g37NhIC20114@aztec.santafe.edu> <200204201727.g3KHRD401381@aztec.santafe.edu> <200204220746.g3M7kvY01878@aztec.santafe.edu> <200204220928.g3M9S9H32293@rum.cs.yale.edu> <3CC40A74.5040600@666.com> <3CC525C5.70400@666.com> <5x7kmyhb6d.fsf@kfs2.cua.dk> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000009090108010406020004" X-Trace: main.gmane.org 1019645732 31545 127.0.0.1 (24 Apr 2002 10:55:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 24 Apr 2002 10:55:32 +0000 (UTC) Cc: Miles Bader , Pavel =?ISO-8859-1?Q?Jan=EDk?= ,Stefan Monnier , Richard Stallman , gerd@gnu.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 170KQu-0008Cg-00 for ; Wed, 24 Apr 2002 12:55:32 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 170KSX-00088q-00 for ; Wed, 24 Apr 2002 12:57:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 170KGz-0002CG-00; Wed, 24 Apr 2002 06:45:17 -0400 Original-Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 170KF6-00025Q-00; Wed, 24 Apr 2002 06:43:20 -0400 Original-Received: from sdn-ap-007caburbp1726.dialsprint.net ([63.184.70.202] helo=666.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 170KF0-0001yK-00; Wed, 24 Apr 2002 03:43:15 -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 X-Accept-Language: en-us Original-To: "Kim F. Storm" Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:3172 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3172 --------------000009090108010406020004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kim F. Storm wrote: >Miles Bader writes: > >>Ben Wing 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... > --------------000009090108010406020004 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Kim F. Storm wrote:
Miles Bader <miles@lsi.nec.co.jp> writes:

Ben Wing <ben@666.com> 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...


--------------000009090108010406020004--