Re: Enhancements to "minor-mode-map-alist" functionality.

[Stefan Monnier]

> However, this can be dramatically simplified by two (simple)
> enhancements to the minor-mode-map-alist functionality:
> 
> 1) Provide a separate emulation-mode-map-alists variable where
> modes like cua can insert their own mode-map-alist,

As you probably know, I'm not too excited about this, since it shouldn't
be necessary if we could enforce a bit more discipline in the way
entries are added to minor-mode-map-alist.
[ Yes, I wish we had "watchers" so we could trap modifications of
  particular variables. ]

But I guess that I can live with it.

BTW, should emulation-mode-map-alists take precedence over
minor-mode-overriding-map-alist or not ?

Also, have you contacted Michael Kifer to see if that would satisfy his
needs for viper (I know he also had to do some funky post-command
fiddling of the minor-mode-map-alist).

> 2) Allow selection of the active keymaps in the alist to
> be based on evaluating a form in addition to a simple variable.

I generally like the idea of having the keymaps more dynamic,
but I'd rather not add another form of dynamism that isn't quite
good enough for everything.  To be more precise, currently you can get
the above "select the keymap dynamically" in a more generic way
(i.e. not just for minor mode maps) by using an entry of the form:

        '(menu-item "foo" data :filter fun)

It is mostly used for dynamic menus, but also works in other keymaps.
Problem is, it only works for submaps because it is not itself
a keymap and thus can't be used for a toplevel map.
So if the dynamism you need is only in the `command-remap' submap,
for example, your new hack is not needed.

I'd rather not add a hack that's specific to minor-mode-map-alist
if we could do the same for all cases instead.

> I have already implemented these features (see attached patch),
> which allows me to configure all the minor mode keymaps needed
> by cua once and for all:

In the patch, you end up evaluating elisp code from a function
that already has a comment about the fact that it needs to be extra-careful
about memory allocation.  Also I'm not sure that all places that call this
function are ready to have elisp code executed at that point (you might
need some GCPROs added here and there).

In other words, maybe we shouldn't evaluate the form inside this
current_minor_maps function.


        Stefan

PS: by the way, isn't it enough to fiddle with minor-mode-map-alist
    in after-load-hook rather than in post-command-hook ?
    [ assuming we had such an after-load-hook. ]