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

[Kim F. Storm]

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

> > Richard Stallman <address@hidden> writes:
> > 
> > >     > That may be true, but I'd like to see what the issue is more 
> > > concretely.
> > >     > If cua and viper tried to use one alist, what would they have to do
> > >     > to prevent it from being messed up?  What does "messed up" mean in 
> > > this
> > >     > context?
> > > 
> > >     Changing the sequence or removing an element from the alist.
> > > 
> > > I don't understand--could you be less cryptic?
> > > That does not seem to answer either one of my questions.
> > > It is not the right kind of answer for either one.
> > 
> > You asked in what way the alist could be "messed up" in "this context".
> > 
> > The "messing up" I'm concerned about is if some other mode
> > (accidentally) changes the sequence of the elements in the alist, or
> > (accidentally) removes one or more of the elements.
> 
> 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).


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

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

++kfs