From mboxrd@z Thu Jan  1 00:00:00 1970
Path: main.gmane.org!not-for-mail
From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
Newsgroups: gmane.emacs.devel
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
Sender: emacs-devel-admin@gnu.org
Message-ID: <200206121519.g5CFJRr18872@rum.cs.yale.edu>
References: <00D3E07D.7CEA4D23.00A66750@netscape.net>
NNTP-Posting-Host: localhost.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1023895303 5457 127.0.0.1 (12 Jun 2002 15:21:43 GMT)
X-Complaints-To: usenet@main.gmane.org
NNTP-Posting-Date: Wed, 12 Jun 2002 15:21:43 +0000 (UTC)
Cc: monnier+gnu/emacs@rum.cs.yale.edu ("Stefan Monnier"),
   ponced16@netscape.net (David Ponce)
Return-path: <emacs-devel-admin@gnu.org>
Original-Received: from quimby.gnus.org ([80.91.224.244])
	by main.gmane.org with esmtp (Exim 3.33 #1 (Debian))
	id 17I9wN-0001Pu-00
	for <emacs-devel@main.gmane.org>; Wed, 12 Jun 2002 17:21:43 +0200
Original-Received: from fencepost.gnu.org ([199.232.76.164])
	by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian))
	id 17IAKE-0000ma-00
	for <emacs-devel@quimby.gnus.org>; Wed, 12 Jun 2002 17:46:22 +0200
Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org)
	by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian))
	id 17I9vs-0001vL-00; Wed, 12 Jun 2002 11:21:12 -0400
Original-Received: from rum.cs.yale.edu ([128.36.229.169])
	by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian))
	id 17I9uC-0001pe-00
	for <emacs-devel@gnu.org>; Wed, 12 Jun 2002 11:19:28 -0400
Original-Received: (from monnier@localhost)
	by rum.cs.yale.edu (8.11.6/8.11.6) id g5CFJRr18872;
	Wed, 12 Jun 2002 11:19:27 -0400
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
Original-To: emacs-devel@gnu.org
Errors-To: emacs-devel-admin@gnu.org
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.0.9
Precedence: bulk
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Post: <mailto:emacs-devel@gnu.org>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
List-Id: Emacs development discussions. <emacs-devel.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://mail.gnu.org/pipermail/emacs-devel/>
Xref: main.gmane.org gmane.emacs.devel:4800
X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4800

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