emacs-devel
[Top][All Lists]
Advanced

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

Re: What happened to the key-menu patch?


From: Stefan Monnier
Subject: Re: What happened to the key-menu patch?
Date: Wed, 10 Jul 2002 14:12:52 -0400

> > > sure if it's worth it to add a `dobindings' macro or not.
> > Agreed.  There's already a `loop' macro for it in CL.
> Yeah, but we don't really like cl in emacs, remember?  Oh wait, you do.

Indeed, I do.  And `loop' is a macro so it only needs CL at compile-time
which is usually regarded as OK.

> > >      key-description list' is, but it's something like (meta control x).
> > >      I guess this is a canonical format for key names in xemacs, but it
> > >      doesn't appear to be so in emacs, so I'm not sure how that argument
> > >      should be handled (perhaps just punt, and pass whatever's stored in
> > >      the keymap).
> > 
> > I don't think we should try to re-create the XEmacs (meta control x) form
> > from our M-C-x symbols.  We could provide an additional compatibility layer
> > on top of it, if it proves useful/necessary later on.
> 
> So, just pass whatever's stored in the keymap directly?

Yes.

> > >  (2) How are menu entries handled with this?
> > 
> > As for how we should treat them, I think we should not do anything
> > special with them: i.e. `function' will be called with key `menu-bar'
> > and with the corresponding sub-keymap as the binding.
> 
> That would be consistent with `lookup-key', but it also throws out
> a bunch of useful information for menu-entries -- in particular, the
> very information that I want for the key-menus!
> 
> How about just passing something similar to the corresponding arguments
> to define-key,

Yes, that's exactly what I meant and what my code does.

> e.g., for keys, `function' would be the function, but
> for menu-entries, it would be the whole (menu-item ...) list.

Yes, but I said `menu-bar' and the thing bound to `menu-bar'
is usually just a keymap because the menubar itself has no name:
only entries inside the keymap bound to `menu-bar' will
have `menu-item' thingies.

> Either way, we have to provide some other sort of function to allow
> easily going from one form to the other -- if we just pass the
> function/sub-keymap, there needs to be a way for the user to lookup all
> the menu-item information, and if we pass the (menu-item...) list
> directly, there should probably be some access function(s) to make
> getting at the various pieces cleanly.

Of course, we need to export some kind of parse-menu-item function,
as was discussed a few weeks/months back.

> Perhaps the thing to do is to pass only the function/sub-keymap by
> default, but have an optional argument that says `pass all menu info for
> menu-items'; this could possible be combined with Richard's suggestion
> of having an option to suppress passing menu-items altogether.

I think it's better to just pas the menu-items all the time: we'll
need the parse-menu-item functionality anyway.

> We could (rather, should) add a similar optional argument to
> `lookup-key' for conistency and utility.

I have also thought about it, but the need has never arisen
(not even in the C code).


        Stefan




reply via email to

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