Re: Assignment of misc packages for emacs

[Miles Bader <miles@gnu.org>]

Richard Stallman <rms@gnu.org> writes:
> The code to understand the menu items has to be somewhere; I don't see
> any reason why it should not be in Lisp.  After all, there is Lisp
> code to create menu items.
> 
> Meanwhile, this creates another ad-hoc representation for the same
> data.

Ok, sounds good to me [I mean, passing a raw keymap to the lisp code].

After looking at the C code more closely, I'm a bit confused about
what's actually happening (my patch just retained the original code for
scanning the keymaps, so I didn't write it).

It seems to use _multiple_ keymaps (the MAPS and NMAPS parameters),
which it merges to get all the menu entries.  Can any explain in what
situation you end up with multiple keymaps that need to be merged like
this?  Should the lisp function be passed a list of keymaps?

It would also be nice to have some helper functions/forms to assist lisp
code in manipulating the keymaps without caring too much about the
details.

For this current application, for instance, I'd like:

  1) something to iterate over the keymaps

     E.g. perhaps (dobindings (VAR KEYMAP [PREDICATE]) BODY..)

  2) accessor functions of some sort for the tricky bits

     For menu-items, as I mentioned earlier, there's already this handy
     C function `parse_menu_item' which could be used to do the bulk of
     the work for any accessor function(s).

     I'm not sure what would be better though, a bunch of individual
     accessor functions, e.g., (menu-item-help MENU-ITEM), or one big
     accessor function like (menu-item-property MENU-ITEM :help).

     The second would probably be easier to implement, since
     parse_menu_item fills in a table, so a general accessor funciton
     like `menu-item-property' could just have a list of
     keyword->table-index mappings.

What are people's opinions about the best way to do these things?
[Stefan...?]

-Miles
-- 
Quidquid latine dictum sit, altum viditur.