emacs-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]