Subject: Re: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows

From: Eli Zaretskii <[email-masked]>
Date: Sun, 18 Dec 2011 20:13:50 +0200

> Date: Sun, 18 Dec 2011 18:31:55 +0100
> From: Joakim Hårsman <[email-masked]>
> 
> > 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 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.