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

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/address@hidden> writes:

> [ I just added Michael to the discussion. ]
> 
> > > The issue of ordering seems academic since I still haven't heard
> > > of any piece of code that accidentally changes the ordering of entries
> > > on minor-mode-map-alist.  Similarly I haven't heard of any case
> > > where an entry is accidentally removed (this would simply be a bug).
> > Ok, it's academic - but if there is a trivial method to avoid having to
> > deal with this issue at all (and viper deals with this in a much more
> > complex manner than cua does).
> 
> As I've explained a while back, there is a trivial method:
> by convention, changing the order of (or removing) entries that do not
> belong to you is a bug.  I.e. any package that changes the ordering of cua
> or viper keymaps has a bug.  Right now I don't know of any such buggy package
> and neither do you, it seems.
> Maybe Michael Kifer does, but my bet is that he does not.  Then again,
> why would anybody go through the trouble of being resilient to such bugs
> if there is no evidence of their existence ?
> 
> 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 thought the only real problem was that you needed your maps to be
> > > at the head of minor-mode-map-alist to take precedence over all others.
> > > (this applies both to cua and viper).
> > True - and both cua and viper want their keymaps to be first ...
> > But that is still only part of the problem.
> 
> That's the part that emulation-map-alist is trying to solve right ?

Exactly!

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.

Take a look at viper to see how it places explicit eval-after-load
hooks on quite a number of minor-mode packages just to be able to
reorganize minor-mode-map-alist after those modes have altered it
[this is an alternative to cua's post-command-hook check].

*Neither* of these "tricks" would be necessary if viper and cua could
just add their own (separate) keymap alist to emulation-mode-map-alists.


> 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 a problem because minor modes (almost) always add themselves
> > > at the head of the list.
> > yes, that's the main form of "messed up" minor-mode-map-alist.
> 
> And that's not too difficult to handle in a post-command-hook,
> although it's admittedly ugly, especially when two or more packages
> fight for "the head of the list" as is the case when you use both cua
> and viper (do they even work together ?).

And especially because there is such a simple way to avoid this hassle:
emulation-mode-map-alists  [or emulation-map-alists if you like
that name better].

I think I have proven that adding emulation-mode-map-alists does solve 
specific problems for modes like cua and viper which uses many minor-mode
keymaps, and want to manage those keymaps separate from the generic
minor-mode-map-alist.

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.

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