Re: Proposal: emulation-mode-map-alist

[Kim F. Storm]

Richard Stallman <address@hidden> writes:

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


I have been considering some more ways to accomplish this:

1) The proposed emulation-mode-map-alist
This simply provides another alist of keymaps to be considered early
on in the process of looking up a key.

The primary "advantage" of this solution is that it would be
very easy to add to the current code.


2) We could have a list of alists, e.g. minor-mode-map-alist-list.
The elements would be symbol names, and the default value would be
   '(minor-mode-overriding-map-alist minor-mode-map-alist)

Packages like cua and viper could insert their own alist symbols at
the head of this list.


3) The list of minor-mode-map-alists could itself be an alist,
   e.g. keymap-alist-alist, where the use of each map-alist is
   controlled by a variable, i.e. the elements would be
   (VARIABLE . KEYMAP-ALIST).

The VARIABLE may also be t to use the KEYMAP-ALIST unconditionally.
The default would then be

        '((t . minor-mode-overriding-map-alist)
          (t . minor-mode-map-alists))

This would allow a whole keymap-alist to be used or ignored via a
single variable (such as CUA-mode), while each of the keymaps in that
alist could be controlled by mode-specific variables.

This would give a very nice way to provide a two-level control over which
keymaps should actually be used, and I can see very good use of this
for cua [and I guess viper could benefit from this as well].
 

4) We could devise a way to keep the existing minor-mode-map-alist in
   a certain order. 

I don't see any easy way to accomplish this, and it definitely is more
complicated (and error-phrone) than the above methods.


5) We could easily enhance the keymap-alist-alist from item 3) with an
   ordering tag, by having each element being a list with three elements
        (ORDER VARIABLE . KEYMAP-ALIST)

The ORDER could be an interger, so that the alist is ordered in
decreasing order.  The default would be:

        '((-1000 t . minor-mode-overriding-map-alist)
          (-2000 t . minor-mode-map-alists))

To ensure proper maintenance of this alist, the following function would be
needed:

  (defun define-keymap-alist (variable keymap-alist &optional order)
   "Add (or remove) VARIABLE . KEYMAP-ALIST to the `keymap-alist-alist'.
If ORDER is specified and is a positive integer, add the element to the list.
If ORDER is nil, remove the element from the list."
   ...)


Given the analysis above, I would like to redraw my proposal for the
emulation-mode-map-alist and propose adding a keymap-alist-alist as
outlined in item 5 above.