bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on


From: Joakim Hårsman
Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows
Date: Mon, 19 Dec 2011 12:50:28 +0100

I'm not the right person to ask, but presumably to remain compatible with 
Windows 95. Not all wide/Unicode apis are available there. 


19 dec 2011 kl. 12:17 skrev Lennart Borgman <lennart.borgman@gmail.com>:

> On Mon, Dec 19, 2011 at 12:04, Joakim Hårsman <joakim.harsman@gmail.com> 
> wrote:
>> On 19 December 2011 11:59, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>> On Mon, Dec 19, 2011 at 11:44, Joakim Hårsman <joakim.harsman@gmail.com> 
>>> wrote:
>>>> On 18 December 2011 19:13, Eli Zaretskii <eliz@gnu.org> wrote:
>>>>>> Date: Sun, 18 Dec 2011 18:31:55 +0100
>>>>>> From: Joakim Hårsman <joakim.harsman@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?





reply via email to

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