Re: Proposal: emulation-mode-map-alist

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/address@hidden> writes:

> 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.

The problem is that a specific package or mode might not have any
clear idea of when its keymap(s) need to be used when combined with
other packages and modes.

>  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.
>

Who should write that function - and how would "new" packages or modes
glue their keymaps into that function?
 
> 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.
> 

I still think maintaining a sensible ordering of a single minor-mode-map-alist
will be too easy to break unless every package knows every other package...

Also, my idea of the keymap-alist-alist has the added bonus of the two-level
variable dependency.

Of course, the minor-mode-map-alist could be modified so that instead of
a simple variable, an arbitrary expression would be allowed, e.g.
an element like this would be allowed:

        ((and x-major-mode y-minor-mody) . keymap)