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

[storm@cua.dk (Kim F. Storm)]

Richard Stallman <rms@gnu.org> writes:

>     It is a list of alists with the same format and interpretation as
>     minor-mode-map-alist.
> 
> Would a single added alist do the job?

I think a package should be able to create its own alist and
link it into the -map-alists list.  Then packages like cua and
viper don't need to worry about each other...

Having one extra alist or a list of alists doesn't make much
difference for the implementation - but it makes a big difference
at the lisp level.

> 
>     Alternatively, an element may look like (lambda . FORM) where FORM is 
>     evaluated and should return either nil or a cons (SYMBOL . KEYMAP);
> 
> That seems kludgy and ugly.

I fully agree.

>                I would rather allow replacing VARIABLE
> with a boolean expression.  Wouldn't that be enough?

So would I, but what symbol should describe-bindings show in case
of a boolean expression?  E.g.

`cua--ena-cua-keys-keymap' Minor Mode Bindings:


Maybe it could just be nil - in which case describe-bindings would print a heading with no specific symbol, e.g.

Misc. Emulation Mode Bindings:

> 
> I think this is the sort of area where it is better to make smaller
> extensions, not larger ones.

I don't think I'm advocating for large extensions here.  The
functionality is confined to adding one new variable, and modifying
one or two functions at the C level.

But I need to take care of the [potential] memory allocation problems
in current_minor_maps.  Either by explicitly defining (and evalling)
a specific set of functions which may be used in the expression, or
by inhibiting evaluation of the boolean expressions if we have run
out of memory.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk