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: Tue, 20 Dec 2011 22:16:53 +0100 [thread overview]
Message-ID: <CAFJF9wXK1xL9cjSTi3c31hwidYFB7h0wTwJRdq6iwj8ZLJdmzQ@mail.gmail.com> (raw)
In-Reply-To: <83pqflzr1d.fsf@gnu.org>
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.
next prev parent reply other threads:[~2011-12-20 21:16 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 [this message]
2012-01-14 16:40 ` Joakim Hårsman
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=CAFJF9wXK1xL9cjSTi3c31hwidYFB7h0wTwJRdq6iwj8ZLJdmzQ@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).