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

[Stefan Monnier]

> > In other words, the issue of accidental reordering and removal of
> > elements from minor-mode-map-alist is a non-issue and should be simply
> > ignored (until further evidence).  It cannot justify *any* change to the
> > code base whatsoever.
> 
> Ok, I agree that if this was the only rationale for my proposal to add
> emulation-mode-map-alists, it would be a mistake to add it.  But that's
> only an added bonus of emulation-mode-map-alists... read on...!

I don't see it as a bonus.  I see it as fog hiding the actual issue.
It's irrelevant.  It's a non-problem.  Solving a non-problem is not
much of a feat.

> If a package can just create its own keymap alist and add it to
> emulation-mode-map-alists, it never has to worry about what other
> modes do to the minor-mode-map-alist.

I agree that the problem cua and viper face is a real problem and
that we should find some way for such packages to add some kind
of minor-mode-like keymaps with a higher precedence than the usual
minor-mode-map-alist.

It seems there are a few alternatives that have been mentioned:

- Using post-command-hook to bring your keymaps back to the head
  of the minor-mode-map-alist.  This works fairly reliably.
  It's not the most elegant solution, but it's OK and it's not as slow
  as it seems since in 99% of the cases it only needs to check for
  (memq (caar minor-mode-map-alist) high-prec-minor-mode-list)
  and only the few rare times when the check fails do we need to do
  more work.
  
- Using after-load-hook (which currently doesn't exist) to do the same thing.
  This can fail if a minor-mode fiddles with the minor-mode-map-alist
  when it's invoked rather than when it's loaded.  A quick look through
  lisp/**/*.el indicates that this can occur sometimes, although rarely.
  Since viper uses a similar approach (based on eval-after-load) it seems
  that the rare cases where the problem can occur are not too serious.

- emulation-mode-map-alist.

- emulation-mode-map-alists.

Of the last two, the second seems more generic but suffers from the fact
that it's not clear what the generality is all about.

> > Does emulation-map-alist solve another problem as well ?
> Yes, it makes it much easier for those packages to setup (and destroy)
> their own keymap alists: just add or remove one element from
> emulation-mode-map-alists rather than 7 or 15 elements from
> minor-mode-map-alist.

This is not what I call "solving a problem".  It is just a very
minor convenience.

> It is true that this is strictly not necessary -- but that doesn't
> address the issue that a *very trivial* addition at the C level [see
> the patch I posted a few minutes ago] makes life *much* easier at the
> lisp level.

Agreed.


        Stefan