unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Joakim Hårsman" <joakim.harsman@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 10299@debbugs.gnu.org
Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows
Date: Sat, 14 Jan 2012 17:40:51 +0100	[thread overview]
Message-ID: <CAFJF9wXqpWbQdXem=VmTgKux1vf+4MpVGp3SLTyYx3gfimhxjQ@mail.gmail.com> (raw)
In-Reply-To: <CAFJF9wXK1xL9cjSTi3c31hwidYFB7h0wTwJRdq6iwj8ZLJdmzQ@mail.gmail.com>

Ok, here's the final version of the patch I'm currently using. It now
only switches to the new behavior when running on NT which should
maintain compatibility with Windows 95. This does make the code
somewhat uglier, but when Emacs stops supporting Windows 95 maybe the
source can be cleaned up and switched to always use the full Unicode
API on all Windows platforms.

I've been using an Emacs with this patch for a couple of weeks now and
haven't discovered any problems so far. I don't have a Windows 95
system to test on though.

=== modified file 'src/w32fns.c'
--- src/w32fns.c        2011-12-04 08:02:42 +0000
+++ src/w32fns.c        2012-01-08 15:30:12 +0000
@@ -1697,10 +1697,13 @@
   if (FRAME_W32_WINDOW (f))
     {
       if (STRING_MULTIBYTE (name))
-       name = ENCODE_SYSTEM (name);
-
+        name = ENCODE_SYSTEM (name);
+
       BLOCK_INPUT;
-      SetWindowText (FRAME_W32_WINDOW (f), SDATA (name));
+      if (os_subtype == OS_NT)
+        SetWindowTextW (FRAME_W32_WINDOW (f), SDATA (name));
+      else
+        SetWindowText (FRAME_W32_WINDOW (f), SDATA (name));
       UNBLOCK_INPUT;
     }
 }
@@ -1746,7 +1749,10 @@
        name = ENCODE_SYSTEM (name);

       BLOCK_INPUT;
-      SetWindowText (FRAME_W32_WINDOW (f), SDATA (name));
+      if (os_subtype == OS_NT)
+        SetWindowTextW (FRAME_W32_WINDOW (f), SDATA (name));
+      else
+        SetWindowText (FRAME_W32_WINDOW (f), SDATA (name));
       UNBLOCK_INPUT;
     }
 }
@@ -1785,20 +1791,39 @@
 static BOOL
 w32_init_class (HINSTANCE hinst)
 {
-  WNDCLASS wc;
-
-  wc.style = CS_HREDRAW | CS_VREDRAW;
-  wc.lpfnWndProc = (WNDPROC) w32_wnd_proc;
-  wc.cbClsExtra = 0;
-  wc.cbWndExtra = WND_EXTRA_BYTES;
-  wc.hInstance = hinst;
-  wc.hIcon = LoadIcon (hinst, EMACS_CLASS);
-  wc.hCursor = w32_load_cursor (IDC_ARROW);
-  wc.hbrBackground = NULL; /* GetStockObject (WHITE_BRUSH);  */
-  wc.lpszMenuName = NULL;
-  wc.lpszClassName = EMACS_CLASS;
-
-  return (RegisterClass (&wc));
+  WNDCLASSW uwc;
+  WNDCLASS  wc;
+
+  if (os_subtype == OS_NT)
+    {
+      uwc.style = CS_HREDRAW | CS_VREDRAW;
+      uwc.lpfnWndProc = (WNDPROC) w32_wnd_proc;
+      uwc.cbClsExtra = 0;
+      uwc.cbWndExtra = WND_EXTRA_BYTES;
+      uwc.hInstance = hinst;
+      uwc.hIcon = LoadIcon (hinst, EMACS_CLASS);
+      uwc.hCursor = w32_load_cursor (IDC_ARROW);
+      uwc.hbrBackground = NULL; /* GetStockObject (WHITE_BRUSH);  */
+      uwc.lpszMenuName = NULL;
+      uwc.lpszClassName = L"Emacs";
+
+      return (RegisterClassW (&uwc));
+    }
+  else
+    {
+      wc.style = CS_HREDRAW | CS_VREDRAW;
+      wc.lpfnWndProc = (WNDPROC) w32_wnd_proc;
+      wc.cbClsExtra = 0;
+      wc.cbWndExtra = WND_EXTRA_BYTES;
+      wc.hInstance = hinst;
+      wc.hIcon = LoadIcon (hinst, EMACS_CLASS);
+      wc.hCursor = w32_load_cursor (IDC_ARROW);
+      wc.hbrBackground = NULL; /* GetStockObject (WHITE_BRUSH);  */
+      wc.lpszMenuName = NULL;
+      wc.lpszClassName = EMACS_CLASS;
+
+      return (RegisterClass (&wc));
+    }
 }

 static HWND
@@ -2248,8 +2273,16 @@

   msh_mousewheel = RegisterWindowMessage (MSH_MOUSEWHEEL);

-  while (GetMessage (&msg, NULL, 0, 0))
+  while (1)
     {
+      if (os_subtype == OS_NT)
+        result = GetMessageW (&msg, NULL, 0, 0);
+      else
+        result = GetMessage (&msg, NULL, 0, 0);
+
+      if (!result)
+        break;
+
       if (msg.hwnd == NULL)
        {
          switch (msg.message)
@@ -2915,8 +2948,21 @@

     case WM_SYSCHAR:
     case WM_CHAR:
-      post_character_message (hwnd, msg, wParam, lParam,
-                             w32_get_key_modifiers (wParam, lParam));
+      if (wParam > 255 )
+        {
+          unsigned short lo = wParam & 0x0000FFFF;
+          unsigned short hi = (wParam & 0xFFFF0000) >> 8;
+          wParam  = hi | lo;
+
+          W32Msg wmsg;
+          wmsg.dwModifiers = w32_get_key_modifiers (wParam, lParam);
+          signal_user_input ();
+          my_post_msg (&wmsg, hwnd, WM_UNICHAR, wParam, lParam);
+
+        }
+      else
+        post_character_message (hwnd, msg, wParam, lParam,
+                                w32_get_key_modifiers (wParam, lParam));
       break;

     case WM_UNICHAR:



On 20 December 2011 22:16, 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 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.
>
> I've fixed the issues with the frame titles, and everything appears to
> work, there are a number of issues I find very confusing however.
>
> Here's the state of my changes as of now:
>
> === modified file 'src/w32fns.c'
> --- src/w32fns.c        2011-12-04 08:02:42 +0000
> +++ src/w32fns.c        2011-12-20 20:46:40 +0000
> @@ -1697,10 +1697,10 @@
>   if (FRAME_W32_WINDOW (f))
>     {
>       if (STRING_MULTIBYTE (name))
> -       name = ENCODE_SYSTEM (name);
> +        name = ENCODE_SYSTEM (name);
>
>       BLOCK_INPUT;
> -      SetWindowText (FRAME_W32_WINDOW (f), SDATA (name));
> +      SetWindowTextW (FRAME_W32_WINDOW (f), SDATA (name));
>       UNBLOCK_INPUT;
>     }
>  }
> @@ -1746,7 +1746,7 @@
>        name = ENCODE_SYSTEM (name);
>
>       BLOCK_INPUT;
> -      SetWindowText (FRAME_W32_WINDOW (f), SDATA (name));
> +      SetWindowTextW (FRAME_W32_WINDOW (f), SDATA (name));
>       UNBLOCK_INPUT;
>     }
>  }
> @@ -1785,7 +1785,7 @@
>  static BOOL
>  w32_init_class (HINSTANCE hinst)
>  {
> -  WNDCLASS wc;
> +  WNDCLASSW wc;
>
>   wc.style = CS_HREDRAW | CS_VREDRAW;
>   wc.lpfnWndProc = (WNDPROC) w32_wnd_proc;
> @@ -1796,9 +1796,9 @@
>   wc.hCursor = w32_load_cursor (IDC_ARROW);
>   wc.hbrBackground = NULL; /* GetStockObject (WHITE_BRUSH);  */
>   wc.lpszMenuName = NULL;
> -  wc.lpszClassName = EMACS_CLASS;
> +  wc.lpszClassName = L"Emacs";
>
> -  return (RegisterClass (&wc));
> +  return (RegisterClassW (&wc));
>  }
>
>  static HWND
> @@ -2248,7 +2248,7 @@
>
>   msh_mousewheel = RegisterWindowMessage (MSH_MOUSEWHEEL);
>
> -  while (GetMessage (&msg, NULL, 0, 0))
> +  while (GetMessageW (&msg, NULL, 0, 0))
>     {
>       if (msg.hwnd == NULL)
>        {
> @@ -2915,8 +2915,21 @@
>
>     case WM_SYSCHAR:
>     case WM_CHAR:
> -      post_character_message (hwnd, msg, wParam, lParam,
> -                             w32_get_key_modifiers (wParam, lParam));
> +      if (wParam > 255 )
> +        {
> +          unsigned short lo = wParam & 0x0000FFFF;
> +          unsigned short hi = (wParam & 0xFFFF0000) >> 8;
> +          wParam  = hi | lo;
> +
> +          W32Msg wmsg;
> +          wmsg.dwModifiers = w32_get_key_modifiers (wParam, lParam);
> +          signal_user_input ();
> +          my_post_msg (&wmsg, hwnd, WM_UNICHAR, wParam, lParam);
> +
> +        }
> +      else
> +        post_character_message (hwnd, msg, wParam, lParam,
> +                                w32_get_key_modifiers (wParam, lParam));
>       break;
>
>     case WM_UNICHAR:
>
> I should probably also only do this on NT (to avoid breaking stuff on
> Windows 95), but that should be easy to fix.
>
> There are a couple of very weird things going on however:
>
> 1. Why is wParam encoded in a weird format spread over the lo and hi
> word of the wParam DWORD?
>
> 2. Why does sending 8-bit strings to SetWindowTextW work, but sending
> 8-bit strings to SetWindowTextA for a window with a "Unicode" window
> class only use the first character?
>
> My guess would be that the correct solution for 2 is to always encode
> frame captions in utf-16le before sending them to SetWindowTextW,
> however I'm not sure what the best way to do this is.
>
> I figure I should use something like this:
>
> Lisp_Object encoding = intern_c_string ("utf-16le-dos");
> name = code_convert_string_norecord (name, encoding, 1);
> SetWindowTextW (FRAME_W32_WINDOW (f), SDATA (name));
>
> Sadly that didn't work (I still get single char frame captions), and I
> never managed to get gdb on Windows to print Lisp objects correctly,
> so I had a hard time understanding why it didn't work. Looking at the
> data that actually gets sent to SetWindowText might make things
> clearer.
>
> Anyway, the current patch works fine as far as I can tell, but it's a
> bit disconcerting to not know *why* things work the way they do.





  reply	other threads:[~2012-01-14 16:40 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-14 20:39 bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Joakim Hårsman
2011-12-15  6:22 ` Eli Zaretskii
2011-12-15  6:51   ` Kenichi Handa
2011-12-15  7:53   ` Joakim Hårsman
2011-12-15 10:52     ` Eli Zaretskii
2011-12-15 11:11       ` Joakim Hårsman
2011-12-15 13:16         ` Eli Zaretskii
2011-12-15 14:40   ` Jason Rumney
2011-12-15 15:08     ` Lennart Borgman
2011-12-15 15:40     ` Joakim Hårsman
2011-12-15 17:34     ` Eli Zaretskii
2011-12-15 20:50       ` Joakim Hårsman
2011-12-15 21:47         ` Joakim Hårsman
2011-12-16  8:13           ` Eli Zaretskii
2011-12-16 11:01             ` Joakim Hårsman
2011-12-16 11:14               ` Dani Moncayo
2011-12-16 11:26                 ` Eli Zaretskii
2011-12-17 12:52                   ` Joakim Hårsman
2011-12-17 15:23                     ` Eli Zaretskii
     [not found]                       ` <CAFJF9wW7Cfmad+BmjQ4A-sVeLi+eRvOXSWfD=--=QJmr3Ver6w@mail.gmail.com>
2011-12-18 18:13                         ` Eli Zaretskii
2011-12-19 10:44                           ` Joakim Hårsman
2011-12-19 10:59                             ` Lennart Borgman
2011-12-19 11:04                               ` Joakim Hårsman
2011-12-19 11:17                                 ` Lennart Borgman
2011-12-19 11:50                                   ` Joakim Hårsman
2011-12-19 13:31                           ` Jason Rumney
2011-12-20 21:16                           ` Joakim Hårsman
2012-01-14 16:40                             ` Joakim Hårsman [this message]
2012-01-16 14:03                               ` Stefan Monnier
2012-01-23 19:15                                 ` Joakim Hårsman
2012-01-24  1:35                                   ` Stefan Monnier
2012-01-24  9:40                                     ` Andreas Schwab
2012-01-24 12:03                                       ` Juanma Barranquero
2012-01-24 20:42                                         ` Joakim Hårsman
2012-07-28 14:50                                           ` Eli Zaretskii
2012-08-06 20:20                                             ` Joakim Hårsman
2012-08-07  2:53                                               ` Eli Zaretskii
2012-08-07 19:47                                                 ` Joakim Hårsman
2012-08-08  2:48                                                   ` Eli Zaretskii
2012-08-08 18:54                                                     ` Joakim Hårsman
2012-08-10  6:56                                                       ` Eli Zaretskii
2012-08-07 12:15                                               ` Jason Rumney
2012-08-07 19:49                                                 ` Joakim Hårsman
2011-12-16 11:22               ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFJF9wXqpWbQdXem=VmTgKux1vf+4MpVGp3SLTyYx3gfimhxjQ@mail.gmail.com' \
    --to=joakim.harsman@gmail.com \
    --cc=10299@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).