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

[Stefan Monnier]

> So the new code fundamentally changes the way key-translation-map works.
> Before, it would be activated immediately, now it is delayed until the
> next key is typed.

Not always.  Only as long as the current key-sequence is a prefix.

> If I still had to rely on the key-translation-map for cua, I'd
> definitely object to this change in behaviour, as it would make it
> impossible to intercept the C-x and C-c prefix keys... which does
> require the "immediate" activation (it obviously cannot wait for the
> next key to be typed).

Very good point.  It's even worse than the last-input-char problem.

> But as we have seen, there may be some nasty effects experienced by
> users which upgrade from, say, 21.1 to 21.4 if they already have the
> old cua-mode in their load-path; in that case, emacs 21.4 will behave
> very strange (read: buggy).  So we need to address that issue!

No argument here.

> 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.

> > Let's say she wants to do C-x C-f so with the new keyboard.c code,
> > when CUA-prefix-handler is called last-input-char is not C-x but C-f,
> > so CUA gets all confused and we end up with C-f C-f whereas
> > CUA thought it wasn't changing anything.
> 
> That is another problem -- caused by key-translation-map not being
> activated immediately; as explained above, that is necessary for
> (old) cua to work properly.  So if it does that, last-input-char
> would be correct again.

Indeed the lasi-input-char issue is minor compared to the fact
that CUA-prefix-handler has to be called immediately.

> > Not knowing exactly what the semantics of last-input-char are supposed
> > to be and how/if functions in key-translation-map should be allowed
> > to use it or should use some other way to figure out what key sequence
> > triggered them, I'm wondering if my fix introduced a "significant"
> > incompatibility or not.
> 
> This is a major incompatibility, but whether it is "significant"
> depends on whether we can find some way of preventing an existing old
> cua-mode package from being loaded instead of the build-in package if
> the user upgrades to 21.4.

I think the incompatibility with old cua is OK since "a fixed cua"
is not only already available but even bundled.  My concern is rather
that it might also happen to other packages for which we have no
such trivial answer.
Emacs-21.1 breaks PCL-CVS-2.9.9 but it's not like anybody cares ;-)

> > Also if it should be fixed, I'm not sure how to go about it.
> See suggestion above.

Yes, thank you,


        Stefan