Re: Old CUA and new keyboard.c (was: Problem with latest CVS version of keyboard.c (solved) )

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/address@hidden> writes:

> > > I was wondering why you need to wait for the next character after a
> > > C-x or C-c to see if they start a function key...  I don't think those
> > > specific keys will ever do that, so maybe you should only delay the
> > > use of key-translation-map in case the key is actually a potential
> > > candidate for starting a function key.
> > 
> > That sounds like a good approach.  I'll see what I can do with it.
> 
> Actually, C-x is already bound in function-key-map in the dumped
> Emacs because of the `C-x @ m', `C-x @ a', ... feature.

So in the future, we cannot remap [C-x] through key-translation-map.
I don't know whether that's critical.  It's not important for me
anymore.

> 
> The change in the code is pretty simple and feels right, so I might
> install it when I've tested it some more, but it doesn't solve the
> problem at hand.
> 

I doubt anyone will notice!

> It seems there's a fundamental incompatibility here.
> On the one hand key-translation-map needs to be applied as soon as C-x
> is pressed and on the other, it should not be applied if the user hits
> C-x @ m.
> 
> Anybody has a good idea how to reconcile those two constraints ?
> Why did cua use key-translation-map rather than a minor-mode keymap ?

Because I didn't know better at the time...

The tricky part was to differentiate between three cases:
1) Normal C-x/C-c when no highlighed region
2) The C-x/C-c cut&copy functionality on highlighted region
3) Retaining the normal prefix meaning if C-x X / C-c X 
   was typed quickly even with highlighted region.

Since key-translation-map allowed mapping to a function,
it seemed logical to use a function which handled all of
these situations.

The new cua does indeed use (several) minor-mode keymaps to
deal with this.

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