From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
Cc: monnier+gnu/emacs@rum.cs.yale.edu ("Stefan Monnier"),
ponced16@netscape.net (David Ponce)
Subject: Old CUA and new keyboard.c (was: Problem with latest CVS version of keyboard.c (solved) )
Date: Wed, 12 Jun 2002 11:19:27 -0400 [thread overview]
Message-ID: <200206121519.g5CFJRr18872@rum.cs.yale.edu> (raw)
In-Reply-To: 00D3E07D.7CEA4D23.00A66750@netscape.net
> >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
next prev parent reply other threads:[~2002-06-12 15:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-12 14:33 Problem with latest CVS version of keyboard.c (solved) David Ponce
2002-06-12 15:19 ` Stefan Monnier [this message]
2002-06-12 22:06 ` Old CUA and new keyboard.c (was: Problem with latest CVS version of keyboard.c (solved) ) Kim F. Storm
2002-06-12 22:31 ` Stefan Monnier
2002-06-12 23:49 ` Stefan Monnier
2002-06-13 5:29 ` Eli Zaretskii
2002-06-13 23:45 ` Kim F. Storm
2002-06-13 23:44 ` Kim F. Storm
2002-06-14 15:14 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200206121519.g5CFJRr18872@rum.cs.yale.edu \
--to=monnier+gnu/emacs@rum.cs.yale.edu \
--cc=ponced16@netscape.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.