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

[storm@cua.dk (Kim F. Storm)]

Richard Stallman <rms@gnu.org> writes:

>     - the new cua need a total of 7 minor mode keymaps, which must be
>       processed in a specific order, and before all other minor mode
>       keymaps
> 
> I am surprised that the present facilities can't be used more easily.
> Could you explain WHY you think this is necessary?  Perhaps there
> is already a better way.

I'm pretty confiden that there isn't a _better_ way already.
There are various ways to do this with the current facilities, but
none of them are really satisfactory (take a look at viper mode's
frequent checking of the minor-mode-map-alist to see what I mean).

I'm trying to come up with a way to transparently enhance emacs'
ability to "change personality" in a way that can be configured
more statically.

> 
>     2) Allow selection of the active keymaps in the alist to
>     be based on evaluating a form in addition to a simple variable.
> 
> Any extension to the keymap mechanism calls for careful thought.
> Please don't rush ahead to install any changes there before we
> have time to discuss this.

Sure!  I did expect some feedback on this, and although my changes
looks fairly simple, I've already been convinced that my approach
isn't sufficiently generic.

> 
> First let's see if change is really needed.  If so, then let's
> understand what the problem is.

I've tried to explain this several times already...

The fundamental problem is that some modes (like viper and cua) makes
some quite fundamental changes to the way some of the standard keys
works [cua remaps C-c and C-x depending on the current state of the
mark (and other conditions), while viper operates in command or insert
mode].

Although the current facilities are sufficient (99% at least), they
_definitely_ are neither elegant, nor efficient, so I would like emacs
to provide some kind of standard feature to better support such modes.

E.g. for cua, I need to ensure that those 7 keymaps are in the front
of minor-mode-map-alist after every command, and I need to set 7
different variables based on the current state so that the next
command can be interpreted correctly... and then I have to be careful
to modify that state if a timer is run which changes the state [which
isn't always possible in theory, although I haven't seen the problem
in practice.]

I'm thinking about other ways to do this...

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