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

[Jason Rumney <jasonr@gnu.org>]

Juanma Barranquero wrote:
> On Dec 12, 2007 6:30 PM, Stefan Monnier <monnier@iro.umontreal.ca> 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
actually means FUNCTION_KEYSTROKE_EVENT, or NON_CHAR_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.