Re: Proposal: emulation-mode-map-alist

[Stefan Monnier]

> >     I guess I could let cua mode do the same, but I've thought about it,
> >     and it seems more generic to introduce a new emulation-mode-map-alist
> >     variable which functions just like minor-mode-map-alist and
> >     minor-mode-overriding-map-alist, but comes before those.
> > 
> > I'd rather not do anything this until we have more experience and it
> > becomes more clear what is the right thing to do here.
> 
> I suggest you take a look at viper-normalize-minor-mode-map-alist
> (and some of the comments accompanying its uses throughout viper).
> IMHO, the experience from that tells us what isn't the right thing to do
> (but with the current functionality probably the only thing to do).
> 
> I really don't want to have to repeat that experience with cua.el which
> is why I tried to come up with a simple, generic solution for modes which
> really don't want anyone else to mess with their keymaps.

There is another related issue which is that sometimes people want to
put global bindings that have precedence over buffer-local bindings
but not over minor-mode bindings.  I can't remember the actual
example right now, tho.

I think a generic solution is to make the whole map-selection "customizable",
à la mode-line-format.  But such a solution is non-trivial and so someone
needs to come up with a good design.  Of course a simple solution is
to just use a `current-active-maps-function' so we can dynamically
decide which maps are active, but it's not so easy to implement
because some parts of the inner read-eval loop currently need to get
that list without allocating memory.

At the opposite end of the spectrum, we can rely on `define-minor-mode'
and friends to provide a controlled access to minor-mode-map-alist
so that you can request for some particular maps to have priority.
Of course, this will fail with code that accesses minor-mode-map-alist
directly, which is why it's good to convert that code to
use define-minor-mode.


        Stefan