all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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

  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.