GNU bug report logs - #10299
Emacs doesn't handle Unicode characters in keyboard layout on MS Windows

Previous Next

Full log

View this message in rfc822 format

From: Joakim Hårsman <joakim.harsman <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10299 <at> debbugs.gnu.org
Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows
Date: Mon, 19 Dec 2011 11:44:55 +0100

On 18 December 2011 19:13, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Sun, 18 Dec 2011 18:31:55 +0100
>> From: Joakim Hårsman <joakim.harsman <at> gmail.com>
>>
>> > That's good news.  However, I'm puzzled: are you saying that the code
>> > points passed by Windows to Emacs for the characters generated by MKLC
>> > are outside the Unicode BMP, i.e. larger than 65535?  If so, what code
>> > points are they?
>>
>> No, none of the characters I needed are outside the BMP.
>>
>> WM_CHAR encodes the codepoint in UTF-16 inside wParam, while
>> WM_UNICHAR uses UTF-32. So if I press something which gives U+2218
>> RING OPERATOR, I get a WM_CHAR event with a wParam of 2228248 or
>> 0x220018.
>
> ??? UTF-16 encodes the characters in the BMP as themselves, i.e. a
> single 16-bit value that is numerically identical to the codepoint.
> That is, you should have gotten 0x2218.  What am I missing?

I just assumed Windows encoded the codepoints into a DWORD in some
funky way, but looking more closely at the documentattion it appears
like wParam should just be the codepoint. Even more strangely, some
places claim that if a keyboard produces a character outside the BMP,
you get two WM_CHAR events.

From what I can tell, Emacs itself never alters wParam, but I guess
Windows might do some funky multibyte encoding since Emacs isn't
completely Unicode?

>> I experimented a bit, and CreateWindowW isn't needed after all. As
>> long as I use RegisterClassW and GetMessageW, things work. I'm unsure
>> if it's TranslateMessage that translates the key press to a question
>> mark or if it's GetMessage that does it on receiving the message.
>
> Question marks are a sign that Windows tried to convert the character
> to its ANSI equivalent, and failed.  I.e., it means that Windows
> thought the program asked for ANSI encoded characters.  So it's
> probably TranslateMessage that did it.
>
>> I'll try to get frame titles working again as well, then I can
>> probably switch on os_subtype in two or three places and Windows 95
>> won't be affected at all. Do you think that is a good plan?
>
> Yes, thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.