From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: Old CUA and new keyboard.c (was: Problem with latest CVS version of keyboard.c (solved) ) Date: Wed, 12 Jun 2002 18:31:25 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200206122231.g5CMVPq21188@rum.cs.yale.edu> References: <00D3E07D.7CEA4D23.00A66750@netscape.net> <200206121519.g5CFJRr18872@rum.cs.yale.edu> <5xelfcup7g.fsf@kfs2.cua.dk> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1023921226 1541 127.0.0.1 (12 Jun 2002 22:33:46 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 12 Jun 2002 22:33:46 +0000 (UTC) Cc: "Stefan Monnier" , emacs-devel@gnu.org, ponced16@netscape.net (David Ponce) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17IGgU-0000Ok-00 for ; Thu, 13 Jun 2002 00:33:46 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17IH4U-0002Fn-00 for ; Thu, 13 Jun 2002 00:58:35 +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 17IGfx-0004vy-00; Wed, 12 Jun 2002 18:33:13 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17IGeJ-0004qg-00 for ; Wed, 12 Jun 2002 18:31:31 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g5CMVPq21188; Wed, 12 Jun 2002 18:31:25 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: storm@cua.dk (Kim F. Storm) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:4808 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4808 > 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