Re: Problem with latest CVS version of keyboard.c (solved)

Re: Problem with latest CVS version of keyboard.c (solved)

[David Ponce]

>Hmm... I don't see it here.  I suspect that it's due to my change
>(Richard's seems unrelated), but could you try to revert only one
>of the two changes, just to make sure which of the two is posing
>problems ?
>
>Does it happen with `-q --no-site-file' ?

No it doesn't.

I think I found the problem:  I used an old version of cua-mode (cua.el
Version: 2.10) which seems to have been broken by recent changes made in
keyboard.c.  After removing this file and using new cua code in the
distribution all worked fine :-)

Thanks all for your time!
David


__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

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

[Stefan Monnier]

> >Hmm... I don't see it here.  I suspect that it's due to my change
> >(Richard's seems unrelated), but could you try to revert only one
> >of the two changes, just to make sure which of the two is posing
> >problems ?
> >
> >Does it happen with `-q --no-site-file' ?
> 
> No it doesn't.
> 
> I think I found the problem:  I used an old version of cua-mode (cua.el
> Version: 2.10) which seems to have been broken by recent changes made in
> keyboard.c.  After removing this file and using new cua code in the
> distribution all worked fine :-)

It's good to see that this problem is solved, but it's important
to try and figure out why things happened that way.  It may very
well be a bug introduced by my change (the code in read_key_sequence
is really intricate)....

...hmm.... it turns out it's a nasty problem:

cua-2.10 puts a CUA-prefix-handler function on C-x in key-translation-map.
This function will remap C-x to something else or to the same
thing depending on the situation.  Problem is, this function
is used for C-c as well (and maybe other keys), so it needs to be
told what was the key that triggered it.
It figures this out by using last-input-char (it also uses this-command-keys
although I'm not quite sure why and what it does with it).

So the problem is that key-translation-map used to be applied immediately
and thus CUA-prefix-handler was called as soon as the user hit C-x, whereas
the new code waits to see whether this C-x starts a function-key
sequence (in which case key-translation-map should not be applied yet)
and thus CUA-prefix-handler is only called once the user hits the next key.

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.

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.
Also if it should be fixed, I'm not sure how to go about it.

Any idea ?  Kim ?


	Stefan

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

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> cua-2.10 puts a CUA-prefix-handler function on C-x in key-translation-map.
> This function will remap C-x to something else or to the same
> thing depending on the situation.  Problem is, this function
> is used for C-c as well (and maybe other keys), so it needs to be
> told what was the key that triggered it.
> It figures this out by using last-input-char (it also uses this-command-keys
> although I'm not quite sure why and what it does with it).

I don't quite remember why this-command-keys was used, but probably it had
something to do with only wanting to remap the first C-c or C-x in a key
sequence.  In any case, that's irrelevant now.

> 
> So the problem is that key-translation-map used to be applied immediately
> and thus CUA-prefix-handler was called as soon as the user hit C-x, whereas
> the new code waits to see whether this C-x starts a function-key
> sequence (in which case key-translation-map should not be applied yet)
> and thus CUA-prefix-handler is only called once the user hits the next key.


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.

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

Since cua no longer depends on this behaviour, and since I'm not aware
of any other code which depends on this, I really don't care much
about the issue.  Also, I'm uncertain whether the behaviour that I
used in cua was actually documented, or it just worked that way by
chance.

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!

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.

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

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

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

See suggestion above.

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

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

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

[Stefan Monnier]

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

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.

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 ?


	Stefan

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

[Eli Zaretskii]

On Wed, 12 Jun 2002, Stefan Monnier wrote:

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

If you can introduce an option which makes the new keyboard code work in 
a way that is compatible with the old code, we could tell the maintainers 
of packages which have this problem to frob that option in their 
initialization code.

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

[Kim F. Storm]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On Wed, 12 Jun 2002, Stefan Monnier wrote:
> 
> > 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 ?
> 
> If you can introduce an option which makes the new keyboard code work in 
> a way that is compatible with the old code, we could tell the maintainers 
> of packages which have this problem to frob that option in their 
> initialization code.

I don't think that's necessary -- and setting that variable would
potentially break new code that relies on the new behaviour.

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

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

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> 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 <storm@cua.dk> http://www.cua.dk

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

[Stefan Monnier]

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

Of course we can.  It's just that the remapping takes place late:
not when you hit C-x but only after you've hit C-x C-f.
So I guess you're right that we cannot remap just [?\C-x], but
we can only remap [?\C-x ...] to [<somethingelse> ...].
Hmmm...


	Stefan