Re: Proposal: emulation-mode-map-alist

[Richard Stallman]

    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.

I think it is the kind of situation where "total generality" can
function as a substitute for solving the real problems.

The difficulty is in making various packages interact correctly in all
combinations; the hard problem is to find a set of features that
packages can use, which will work together in combination.

To implement a `current-active-maps-function' would just push the hard
problem off on the user, not solve it.  I am sure we subsequently
would see various packages redefine `current-active-maps-function' to
achieve their own goals, and then they would not work togethe.

This is a general principle: when various packages want to extend an
area in different ways, our mission is to define a framework that
permits the specific kinds of extensions they need while enabling them
to work together.  To say "let the user redefine the whole thing" is
to abandon the mission.

Kim F Storm wrote:

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

    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

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.

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

    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.

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.

    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.

    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)

This added feature would not really make anything easier to use.

The smaller complexity of #2 might be worth while; there is certainly
no need to go further.