[Top][All Lists]

[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: Mon, 22 Apr 2002 06:04:52 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/20020314 Netscape6/6.2.2

Stefan Monnier wrote:
       > It might not be easy to find key bindings for it, though.

I think it is very easy. We should use F10, and invent new variable
f10-should-use-tmm (this is only idea to exactly describe its meaning...)
defaulting to nil.

What key bindings does XEmacs use for this feature?
Maybe we should use the same ones, if there is no disadvantage.

I think they use A-<letter> to pop down the menu whose
first letter is <letter> and then the same kind of thing to select
entries inside menus (and probably A-next and A-prior to select by
moving line-by-line).
I believe it was chosen because it's what Motif and W32 interfaces
provide (and I expect GTK to offer similar things). It has the
disadvantage of relying on the presence of an Alt key which is not
already used as a Meta key.

This all comes from my very fuzzy memory, so I'm sure it's good
several "inaccuracies".

currently, either:

-- if you have an alt key separate from meta, you can use it for menu accelerators.
-- otherwise, you can use the standard alt/meta key -- meta+any accelerator letter selects a menu, otherwise you get the regular behavior.  for any shadowed binding, meta+shift+letter ignores the accelerator and gets you the shadowed binding [or alternatively, use esc+letter, which also ignores the accelerator].  you can turn this on and off, of course, and pick what key is your accelerator.  i've designed our menus in such a way that there is little interference from losing some of the M-foo combinations -- there are generally equivalent arrow-key bindings, or you can just pick an item off the menu.

i program under windows, so i interfaced to the standard windows menu stuff.

btw i would really appreciate it if you guys could keep a recent version of xemacs around so you can run it and see, and keep compatible whenever possible rather than reinvent the wheel.  i constantly refer to the most recent gnu emacs source code when thinking about making changes [to keep compatibility whenever possible] and it would be really good if you guys could also try to keep compatible.  keep in mind that the theoretical eventual goal is partial or total merger of the two, and every time you add a feature that's incompatible with xemacs you make that goal harder to achieve.

i know you can't look at the source code directly due to self-imposed restrictions, but

[a] you can run the program and use the help system,
[b] you can [maybe?] look at the changelogs,
[c] you should arrange one of you who doesn't work on the gnu emacs code as official "xemacs code reader" when such issues need to be resolved.


Emacs-devel mailing list

reply via email to

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