[Top][All Lists]

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

Re: assertion failed: c == event->code

From: Jason Rumney
Subject: Re: assertion failed: c == event->code
Date: Thu, 13 Dec 2007 14:16:35 +0000
User-agent: Thunderbird (Windows/20071031)

Juanma Barranquero wrote:
> On Dec 12, 2007 6:30 PM, Stefan Monnier <address@hidden> wrote:
>> Hmm.. if you just remove this eassert, you should get back the previous
>> behavior.  But then I wonder: is this previous behavior correct, and if
>> so, why?
> No idea.
>> Basically, the issue is that when a key is pressed, the W32 code inserts
>> a "ASCII_KEYSTROKE_EVENT" in the queue, even for non-ASCII chars, and
>> then keyboard.c applies a "& 0377" to it, so there's a risk of losing
>> some bits and turning a non-ASCII keypress into some ASCII char.
> Without the eassert, C-ñ returns ' (U+2018, translated from \221), C-ç
> returns ‡ (U+2021, translated from \207). Not sure whether that is
> intended or not.
What is your locale set to, and keyboard-coding-system?
Also, does this happen with emacs -Q?

Since Windows effectively blocks Cntl and AltGr being used together, the
only sequences I can type are C-£ and C-¬, both of which work correctly
with a UK English Windows locale, and keyboard-coding-system set to cp1252.

Looking at the actual code for ASCII_KEYSTROKE_EVENT, it really means
UNIBYTE_CHAR_KEYSTROKE_EVENT, as the mask is against \0377 (0xff), and a
test in xterm.c tests for SINGLE_BYTE_CHAR_P.

Other naming in that enum is not clear, as NONASCII_KEYSTROKE_EVENT

MULTIBYTE_CHAR_KEYSTROKE_EVENT seems clearer, but it is not clear from
the comments, nor the code in xterm.c, whether it should be an
emacs-mule encoded character, or a double byte character in the keyboard
coding system, as the code in xterm.c seems to generate both.

reply via email to

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