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
On Mon, Dec 19, 2011 at 12:04, Joakim Hårsman <joakim.harsman <at> gmail.com> wrote:
> On 19 December 2011 11:59, Lennart Borgman <lennart.borgman <at> gmail.com> wrote:
>> On Mon, Dec 19, 2011 at 11:44, Joakim Hårsman <joakim.harsman <at> gmail.com> wrote:
>>> 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?
>>
>> Maybe Emacs on windows still is using the ANSI version of DefWindowProc? See
>>
>> http://blogs.msdn.com/b/michkap/archive/2007/03/25/1945659.aspx
>
> I looked at that page as well, but it says that the ANSI DefWindowProc
> is supposed to post one or two ANSI characters, and it definitely
> isn't doing that. I get teh correct Unciode character, just spread
> over the low and high word of the wParam dword.
Strange. What is the reason Emacs is still using the ANSI version?
Maybe a mix of ANSI and UNICODE versions gives strange results?
This bug report was last modified 12 years and 289 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.