Re: C-l while in menu?

[Ben Wing]

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
> address@hidden
> http://mail.gnu.org/mailman/listinfo/emacs-devel
>
>