[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enhancements to "minor-mode-map-alist" functionality.
From: |
Kim F. Storm |
Subject: |
Re: Enhancements to "minor-mode-map-alist" functionality. |
Date: |
09 May 2002 02:58:56 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 |
"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
- Re: Enhancements to "minor-mode-map-alist" functionality., (continued)
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/05/03
- Re: Enhancements to "minor-mode-map-alist" functionality., Richard Stallman, 2002/05/03
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/05/04
- Re: Enhancements to "minor-mode-map-alist" functionality., Richard Stallman, 2002/05/05
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/05/05
- Re: Enhancements to "minor-mode-map-alist" functionality., Richard Stallman, 2002/05/07
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/05/07
- Re: Enhancements to "minor-mode-map-alist" functionality., Stefan Monnier, 2002/05/07
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/05/08
- Re: Enhancements to "minor-mode-map-alist" functionality., Stefan Monnier, 2002/05/08
- Re: Enhancements to "minor-mode-map-alist" functionality.,
Kim F. Storm <=
- Re: Enhancements to "minor-mode-map-alist" functionality., Stefan Monnier, 2002/05/08
- Re: Enhancements to "minor-mode-map-alist" functionality., Miles Bader, 2002/05/08
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/05/09
- Re: Enhancements to "minor-mode-map-alist" functionality., Richard Stallman, 2002/05/08
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/05/08
- Re: Enhancements to "minor-mode-map-alist" functionality., Richard Stallman, 2002/05/09
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/05/10
- Re: Enhancements to "minor-mode-map-alist" functionality., Richard Stallman, 2002/05/11
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/05/11
- Re: Enhancements to "minor-mode-map-alist" functionality., Richard Stallman, 2002/05/13