Re: C-l while in menu?

[Ben Wing <ben@666.com>]

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



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.

>
>
>
>	Stefan
>
>
>_______________________________________________
>Emacs-devel mailing list
>Emacs-devel@gnu.org
>http://mail.gnu.org/mailman/listinfo/emacs-devel
>


[-- Attachment #2: Type: text/html, Size: 3573 bytes --]