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

[Kim F. Storm]

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

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

Ok, I've agreed that is is a minor/non-issue...
But we seem to agree that there is a "real" issue here.

> It's irrelevant.  It's a non-problem.  Solving a non-problem is not
> much of a feat.

Ok, it's a non-issue then.  And by adding emulation-mode-map-alists it
will never become an issue :-)

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

Good!!!

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

I hate this solution.  It's an ugly kludge; it adds code which
"repairs" something which should never be a problem, and I agree with
Miles that, it's the wrong kind of thing to do in a post-command-hook.

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

Ok, but again, it's a real kludge; it breaks as soon as someone adds a
minor mode which viper doesn't know about...

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

If the documentation is inadequate, please help me improve it:

,------------
| emulation-mode-map-alists's value is (cua--keymap-alist)
| 
| Documentation:
| List of keymap alists to use for emulations modes.
| It is intended for modes or packages using multiple minor-mode keymaps.
| Each element is a keymap alist just like `minor-mode-map-alist', or a
| symbol with a variable binding which is a keymap alist, and it
| is used the same way.  The "active" keymaps in each alist are used before
| `minor-mode-map-alist' and `minor-mode-overriding-map-alist'.
`-----------

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

Again it's just an added bonus, but a very convenient one!

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

So can I go ahead and add emulation-mode-map-alists ?
[Ref: the patch I sent out yesterday]

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