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

[Kim F. Storm]

Richard Stallman <address@hidden> writes:

> 
>      -- I'm trying to find the
>     right approach to address the issues with complex modes which uses a
>     lot of keymaps (like cua and viper) and base the selection between
>     those keymaps on combining various state information
> 
> Selecting between keymaps is one possible avenue for doing a certain
> job.  Before we assume it should be done this way, what are the other
> avenues?  What is the job?

Consider C-x.

Normally, it works as a prefix key for things like C-x C-f etc.

Basically, with cua, if the mark is active, hitting C-x starts a 0.2 seconds 
timer.

If the timer runs out, C-x works like C-w (kill-ring-save).

If the user enters another C-x within those 0.2 seconds, the first C-x
is ignored and the second C-x works like a normal prefix key.

Also if the user enters another key, e.g. C-f, within those 0.2 seconds,
the first C-x now works like a prefix key, i.e. as C-x C-f.

[all of this was discussed a year ago as ways to let the user circumvent
cua's C-x handling].

The actual interpretation of C-x is done via three of cua's 7 keymaps.


To complicate things, cua also supports rectangles and a global mark, which
all work using the same command set as is used for the region, e.g. you
also use C-x (or C-w) to kill the rectangle  (and C-y to insert it), or
if the global mark is set, C-x will move the selected region or rectangle
to the global mark position...

To facilitate this, three more keymaps are used which selectively does
command remapping of `kill-ring-save' to handle either region, rectangle,
or the global mark.

The final keymap is used to allow users to take advantage of cua's
uniform command set for rectangles (and the global mark), but still
continue to use C-w, M-w and C-y instead of C-x, C-c, and C-v (which
are the normal cua bindings).


Having gone through a major overhaul of the cua code, I can definitely
say that basing this on multiple minor-mode keymaps is a major improvement.
The primary advantage is that code is much simpler to maintain now.

> 
>     I have N keymaps which all make bindings starting with C-x -- and I want
>     all of those bindings to "work".
> 
> What job are these bindings supposed to *do*?  Given time I could
> figure that out from the code you sent, but I don't have that time.
> 
Ok, but considering that I've spent more than 200 hours on this project
maybe you could give my views some weight -- I have tried various alternatives
to the current approach, and it is by far the best approach so far!!

>     If it wasn't for the problem evalling code in the current_minor_maps
>     function [I believe there are ways to solve that], would that solution
>     be acceptable?
> 
> Not necessarily.  It would still be a big extension in an area where
> the code is already too complex.  Multiple inheritance is inherently a
> mess.  Once it was added, it would probably require subsequent work to
> fix bugs or to add more features so people can "fully use" it.


The emulation-mode-map-alist and conditioned keymaps doesn't add
multiple inheritance  (that was part of my other proposal, once the
emulation-mode-map-alist idea was rejected).  It is primarily a
way for packages like cua to be able to configure its (multiple)
keymaps once and for all without worrying about other packages
messing them up.

I don't see why this is a significant complication.

And what ever errors is potentially associated with it, I feel
confident I can fix.

> 
>     > Multiple inheritance is a mess.  We should avoid it if we can.
> 
>     But the `parent keymap' inheritance is already pretty messy.
> 
> That is why we should not make it any hairier.
> 
> Please don't use arguments of the form "We already have this kind of
> problem, therefore it it doesn't matter if we add to it."  That is the
> wrong approach for any serious problem, and I can promise you I will
> say no.
> 

Ok, since this wasn't really an issue with my initial proposal (the
emulation-mode-map-alist), I will leave it to Stefan to defend any
changes added for the purpose of multiple inheritance.

Please do not confuse my requirements for cua with multiple
inheritance issues.

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