[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs 21.3, Linux tty: Meta gets lopped off of C-M-g

From: Alan Mackenzie
Subject: Re: Emacs 21.3, Linux tty: Meta gets lopped off of C-M-g
Date: Sun, 28 Mar 2004 09:39:25 +0000 (GMT)

On Sat, 27 Mar 2004, Richard Stallman wrote:

>    At Emacs 21.3 on a Linux tty, something in Emacs's low-level
>    keyboard handling appears to be mangling the key event C-M-g,
>    silently discarding the "M-", leaving C-g.

>It is converting C-M-g into ESC C-g, .....

It also converts C-M-a int ESC C-a.  Then it looks up ESC in the keymaps,
finds it bound to a keymap itself, looks up C-a in this esc-keymap and
finds `beginning-of-defun'.

However, with C-M-g, things are different.  Emacs apparently says "Even
though the user didn't type C-g, just in case that's what she really
meant, I'd better discard the ESC rather than looking up ESC in a
keymap.".  This is not a Good Thing.

If I manually type ESC C-g, Emacs executes whatever I have bound to
C-M-g.  Emacs does not discard the ESC in this case, and does not
interpret the C-g as a quitting request.

> .... but C-g in Emacs is the quit character.

C-g the _keyboard_ _action_ is for quitting.  ASCII 0x07, C-g the
_character_, should be looked up in the currently active keymaps.  It
seems Emacs is getting confused between these two things.  In particular,
Emacs should never process an ASCII 0x07 which it has itself generated,
as though it were a C-g keyboard action.

> There is nothing Emacs can do about this.

Hey, what's all this with the fairy stories?  ;-)

It's done successfully in X-Windows, which receives the same fundamental
key events that a tty does.

WHY is it necessary to discard ESC from ESC C-g?

I'd very much appreciate somebody telling me where the code is that
translates the raw keyboard input for C-M-<letter> into ESC C-<letter>.
(I've been looking for some hours without finding it).  Presumably it's
within the C code, not the Lisp code.  In keyboard.c, somewhere?

Alan Mackenzie (Munich, Germany)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]