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

[Joakim Hårsman]

I'm well aware of the insanity of this patch, but trust me, it does
actually work, I use a version built with this patch every day.

The reason for the weirdness is the partial use of Unicode APIs, this
lead to lots of weirdness with wide strings being interpreted as
single byte strings in various places.

But it doesn't matter anymore, Eli's modifications removes all of the
ugliness and work fine.

On 7 August 2012 14:15, Jason Rumney <jasonr@gnu.org> wrote:
> Joakim Hårsman <joakim.harsman@gmail.com> writes:
>
>>>
>>>   +/* Set text of w32 frame with handle HWND to TEXT.
>>>   +
>>>   +   We explicitly switch between the Unicode and ANSI version of
>>>   +   SetWindowText because Emacs isn't compiled with UNICODE defined to
>>>   +   retain compatibility with Windows 95. */
>>>   +
>>>   +static void
>>>   +w32_set_frame_text (HWND hwnd, LPCSTR text)
>>>   +{
>>>   +  if (os_subtype == OS_NT)
>>>   +    SetWindowTextW (hwnd, (LPCWSTR)text);
>>>   +  else
>>>   +    SetWindowTextA (hwnd, text);
>>>   +}
>
>> The change to SetWindowTextW for frame titles was needed because
>> otherwise the frame title was cut short after the first character
>> (presumably because the window class name is a UCS-2 wide string and
>> the second byte therefore is null). This is exaclty the case they talk
>> about at your link.
>
>>>          if (STRING_MULTIBYTE (name))
>>>   -       name = ENCODE_SYSTEM (name);
>>>   -
>>>   +        name = ENCODE_SYSTEM (name);
>>>   +
>>>          BLOCK_INPUT;
>>>   -      SetWindowText (FRAME_W32_WINDOW (f), SDATA (name));
>>>   +      w32_set_frame_text(FRAME_W32_WINDOW (f), SDATA (name));
>
> But the above doesn't pass a UCS-2 wide string to SetWindowTextW.  It
> passes an 8-bit string encoded in the system 8-bit encoding, then simply
> casts it to a wchar_t!  You cannot possibly get the correct frame title using
> this patch.
>
>