[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: |
03 May 2002 21:08:41 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 |
Richard Stallman <address@hidden> writes:
> > Would a single added alist do the job?
>
> I think a package should be able to create its own alist and
> link it into the -map-alists list.
>
> I am not convinced. I very much want to avoid adding more features in
> this area than we really need.
I still think that addition of the emulation-mode-map-alist does not
add to the complexity of emacs' keymap functionality [I've already
written the code, and it is trivial] -- it actually makes it simpler
for packages to setup their own keymaps.
I don't have any _new_ arguments in favour of this view -- but I really,
really, really feel strongly that the current features are inadequate.
Yes, they can do the job, but only provided that a post-command-hook
is used to ensure the consistency of the keymap setup and prepare
the conditions for the next key sequence to be read.
Having (re-)written the code for cua several times by now, I really
feel that the `emulation-mode-map-alists' feature is both _simple_,
_efficient_, and _trivial_ to implement.
>
> Then packages like cua and
> viper don't need to worry about each other...
>
> I don't know what this is about. What concretely does this refer to?
If you enable both cua and viper, they both have a post-command-hook
function which reorders the minor-mode-map-alist to meet their own
requirements... so in effect you get the minor-mode-map-alist shuffled
and reshuffled twice after each command. And since cua has 7 keymaps
and viper has 9 keymaps, this is a lot of "non-minor" mode keymaps
messing up the minor-mode-map-alist .... which could simply have been
organized into two separate keymap alists _permanently_ linked into the
emulation-mode-map-alists list [with no need for a post-command-hook
function to reorder them after each command].
> Let's see what the alternatives really are and then compare them.
>
> So would I, but what symbol should describe-bindings show in case
> of a boolean expression? E.g.
>
> None, perhaps. It can just call them "emulation mode bindings".
That's fine with me!
++kfs
- Re: Enhancements to "minor-mode-map-alist" functionality., Richard Stallman, 2002/05/01
- Re: Enhancements to "minor-mode-map-alist" functionality., Kim F. Storm, 2002/05/01
- Re: Enhancements to "minor-mode-map-alist" functionality., Richard Stallman, 2002/05/02
- Re: Enhancements to "minor-mode-map-alist" functionality.,
Kim F. Storm <=
- 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, 2002/05/08