Re: Proposal: emulation-mode-map-alist

[Kim F. Storm]

Richard Stallman <address@hidden> writes:

> I won't reject emulation-mode-map-alist out of hand, but first
> let's look for a simpler possible solution:
> 
> * Most minor modes should add themselves at the end of minor-mode-alist.

Currently, add-minor-mode (and thus define-minor-mode) adds the
keymap at the head of minor-mode-map-alist, but that could be changed.

> 
> * Those that are "emulations" and need to come first should add
>   themselves at the beginning instead.
> 
> * This should work just as well as emulation-mode-map-alist,
>   as long as the convention is followed.
>

The problem is to ensure the convension is followed - especially if
packages modify minor-mode-map-alist directly.
 
>     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)
> 
> If we end up adding emulation-mode-map-alist, using a list like this
> to define it is ok.  However, we should think of this as internal, and
> predefine emulation-mode-map-alist in it, not invite packages like cua
> to add their own.

I think that minor-mode-map-alist-list should be public!  Then we
don't need the emulation-mode-map-alist at all, since emulation
packages simply add their own map-alist to the minor-mode-map-alist-list.

This is useful for modes like viper and cua, since they want to add
several minor-mode keymaps, so I think it would be simpler for those
packages to add their own viper-mode-map-alist or cua-mode-map-alist
(which no other packages will mess up) to the head of the
minor-mode-map-alist-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).
> 
> I see no benefit from this added complexity.

I do see at least one benefit! Let me use cua as an example.

Cua has three different minor modes: region, rectangle, and global mark.
So I would like to use three minor-mode keymaps for these, each
controlled by a variable CUA-mark, CUA-rectangle, and CUA-global-mark:

  (setq CUA-mode-map-alist
        '((CUA-mark CUA-mark-mode-map)
          (CUA-rectangle CUA-rectangle-mode-map)
          (CUA-global-mark CUA-global-mark-mode-map)))

At the same time, I would also like to control the entire cua mode by
the variable CUA-mode, i.e. if CUA-mode is nil, the value of the above
variables should be ignored, and so should their minor-mode keymaps.

With the minor-mode-map-alist-alist, I could let cua place its own
CUA-mode-map-alist into minor-mode-map-alist-alist controlled by CUA-mode:

  (setq minor-mode-map-alist-alist
        (cons '(CUA-mode CUA-mode-map-alist) minor-mode-map-alist-alist))

Without this feature, I need to use a post-command-hook function to 
turn off the CUA-mark, CUA-rectangle, and CUA-global-mark variables
if CUA-mode is nil.

Actually, some of the functionality of cua could be simplified by simply
checking on mark-active rather than maintaning a separate CUA-mark variable.

So this two-level control does have it's benefits.

And since we already have the code to do this (in the parsing of
minor-mode-map-alist), I don't really see why it is that complex?


If you like, I volounteer to make the necessary changes to add the
minor-mode-map-alist-alist (or just -list if you insist :-).

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