From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 14 Dec 2011 20:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 10299@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs Received: via spool by submit@debbugs.gnu.org id=B.132389526331468 (code B ref -1); Wed, 14 Dec 2011 20:42:02 +0000 Received: (at submit) by debbugs.gnu.org; 14 Dec 2011 20:41:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RavdO-0008BU-Fu for submit@debbugs.gnu.org; Wed, 14 Dec 2011 15:41:03 -0500 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RavdM-0008B6-0u for submit@debbugs.gnu.org; Wed, 14 Dec 2011 15:41:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ravbw-0001P9-W2 for submit@debbugs.gnu.org; Wed, 14 Dec 2011 15:39:34 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:36328) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ravbw-0001P5-TL for submit@debbugs.gnu.org; Wed, 14 Dec 2011 15:39:32 -0500 Received: from eggs.gnu.org ([140.186.70.92]:44217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ravbv-0002e0-P2 for bug-gnu-emacs@gnu.org; Wed, 14 Dec 2011 15:39:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ravbu-0001Oo-Mx for bug-gnu-emacs@gnu.org; Wed, 14 Dec 2011 15:39:31 -0500 Received: from mail-ey0-f169.google.com ([209.85.215.169]:43595) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ravbu-0001Ok-EK for bug-gnu-emacs@gnu.org; Wed, 14 Dec 2011 15:39:30 -0500 Received: by eaai13 with SMTP id i13so1447940eaa.0 for ; Wed, 14 Dec 2011 12:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Mtsj49P4Y7HgJbm0BRy+7OJZlpJDuNOTB/IHCn41ED4=; b=EGIQnWvGMIP1oNeLnbtGxad6dR17bpTpE3ygUiZ4GTg7Rf1kG+H50sV5jT4s2JA84C rszIqAwsqbQsvvmCeJxQWSsCV1Ann66CUc1VcqP0Dye7Har45Tlj2i6fjYgRA4Nezlr2 zROeSAHZgPgL28MaDYiPZCLKzxJ5VAKeLn4zY= MIME-Version: 1.0 Received: by 10.205.125.144 with SMTP id gs16mr21976bkc.137.1323895168962; Wed, 14 Dec 2011 12:39:28 -0800 (PST) Received: by 10.205.40.130 with HTTP; Wed, 14 Dec 2011 12:39:28 -0800 (PST) Date: Wed, 14 Dec 2011 21:39:28 +0100 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.4 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.6 (-----) In MS Windows, users can easily create custom keyboard layouts using Microsoft Keyboard Creator [1]. This can be used to for example to make typing certain Unicode symbols easier (like Greek letters when typing mathematical formula), and is very useful. However, Emacs doesn't seem to handle the case when the keyboard layout contains characters not available in the ANSI code page, and just prints a question mark character instead. For certain characters, a character that is visually similar to the actual character is printed instead of a question mark. For example, if I use a layout where AltGr+O produces U+2218 RING OPERATOR, Emacs prints U+00B0 DEGREE SYMBOL instead. The degree symbol is available in Windows 1252, the default ANSI code page on my system, but the ring operator isn't. However, if the layout maps AltGr+R to U+0220A SMALL ELEMENT OF, Emacs just prints a question mark, presumably because Windows 1252 doesn't contain a reasonable replacement for that character. I can reproduce this on Emacs 24.0.92.1 (i386-mingw-nt5.1.2600) even when started with -q to skip any customization. I'd be happy to help debug this but I have no idea where to even start. Is there an easy way to find out if it's the C code that clobbers the character or if it happens in lisp for example? [1]: http://msdn.microsoft.com/en-us/goglobal/bb964665 From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Dec 2011 06:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: jasonr@gnu.org, 10299@debbugs.gnu.org, handa@m17n.org Reply-To: Eli Zaretskii Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132393022317405 (code B ref 10299); Thu, 15 Dec 2011 06:24:01 +0000 Received: (at 10299) by debbugs.gnu.org; 15 Dec 2011 06:23:43 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rb4jG-0004Wf-NE for submit@debbugs.gnu.org; Thu, 15 Dec 2011 01:23:43 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rb4jE-0004WX-29 for 10299@debbugs.gnu.org; Thu, 15 Dec 2011 01:23:40 -0500 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Rb4hn-0002C6-5C; Thu, 15 Dec 2011 01:22:11 -0500 Date: Thu, 15 Dec 2011 01:22:11 -0500 Message-Id: From: Eli Zaretskii In-reply-to: (message from Joakim =?UTF-8?Q?H=C3=A5rsman?= on Wed, 14 Dec 2011 21:39:28 +0100) References: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > Date: Wed, 14 Dec 2011 21:39:28 +0100 > From: Joakim Hårsman > > However, Emacs doesn't seem to handle the case when the keyboard > layout contains characters not available in the ANSI code page, and > just prints a question mark character instead. Yes, Emacs on Windows uses the ANSI codepage to read the keyboard input. Does it help to play with the value of keyboard-coding-system? > For certain characters, > a character that is visually similar to the actual character is > printed instead of a question mark. For example, if I use a layout > where AltGr+O produces U+2218 RING OPERATOR, Emacs prints U+00B0 > DEGREE SYMBOL instead. The degree symbol is available in Windows 1252, > the default ANSI code page on my system, but the ring operator > isn't. I'm guessing that this is Windows trying to translate the characters to the ANSI codepage behind the scenes. > However, if the layout maps AltGr+R to U+0220A SMALL ELEMENT OF, Emacs > just prints a question mark, presumably because Windows 1252 doesn't > contain a reasonable replacement for that character. Will inputting these characters with "C-x 8 RET 0220a RET" or "C-x 8 RET SMALL ELEMENT OF RET" be a good enough solution for you? You can input any Unicode character by its name or codepoint using "C-x 8 RET". > I'd be happy to help debug this but I have no idea where to even > start. Is there an easy way to find out if it's the C code that > clobbers the character or if it happens in lisp for example? I don't think there any "clobbering". Emacs deliberately converts the Unicode characters to the current locale's ANSI codepage. I think (but I'm not sure) the reason is that Emacs cannot use UTF-16 for keyboard input. Perhaps Jason and Handa-san could comment on this. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows References: Resent-From: Kenichi Handa Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Dec 2011 06:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 10299@debbugs.gnu.org, joakim.harsman@gmail.com, jasonr@gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132393197319996 (code B ref 10299); Thu, 15 Dec 2011 06:53:02 +0000 Received: (at 10299) by debbugs.gnu.org; 15 Dec 2011 06:52:53 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rb5BS-0005CR-SZ for submit@debbugs.gnu.org; Thu, 15 Dec 2011 01:52:53 -0500 Received: from mx1.aist.go.jp ([150.29.246.133]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rb5BO-0005CC-V3 for 10299@debbugs.gnu.org; Thu, 15 Dec 2011 01:52:49 -0500 Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id pBF6pDUT028510; Thu, 15 Dec 2011 15:51:13 +0900 (JST) env-from (handa@m17n.org) Received: from smtp1.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id pBF6pDTQ009262; Thu, 15 Dec 2011 15:51:13 +0900 (JST) env-from (handa@m17n.org) Received: by smtp1.aist.go.jp with ESMTP id pBF6pCa8016490; Thu, 15 Dec 2011 15:51:12 +0900 (JST) env-from (handa@m17n.org) From: Kenichi Handa In-Reply-To: (message from Eli Zaretskii on Thu, 15 Dec 2011 01:22:11 -0500) Date: Thu, 15 Dec 2011 15:51:12 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.8 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) In article , Eli Zaretskii writes: > I don't think there any "clobbering". Emacs deliberately converts the > Unicode characters to the current locale's ANSI codepage. I think > (but I'm not sure) the reason is that Emacs cannot use UTF-16 for > keyboard input. Perhaps Jason and Handa-san could comment on this. Currently only ASCII compatible coding system can be used for keyboard-coding-system. But, keyboard-coding-system is for decoding tty input. On graphic device, Emacs can decode a system event directly. For instance, handle_one_event (in xterm.c) decodes the output of XIM (X Input Method) directly. --- Kenichi Handa handa@m17n.org From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Dec 2011 07:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: jasonr@gnu.org, 10299@debbugs.gnu.org, handa@m17n.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132393568725478 (code B ref 10299); Thu, 15 Dec 2011 07:55:01 +0000 Received: (at 10299) by debbugs.gnu.org; 15 Dec 2011 07:54:47 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rb69P-0006ct-8x for submit@debbugs.gnu.org; Thu, 15 Dec 2011 02:54:47 -0500 Received: from mail-ey0-f172.google.com ([209.85.215.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rb69N-0006cn-8b for 10299@debbugs.gnu.org; Thu, 15 Dec 2011 02:54:46 -0500 Received: by eaad1 with SMTP id d1so1565811eaa.3 for <10299@debbugs.gnu.org>; Wed, 14 Dec 2011 23:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jecuTEJQgDO3V3EtRe1+839L4Gl7UofK+qV9JxBSe3k=; b=VyWWgVVC+3V6H+ESWGba2Uzyudm0cUqpUTruSiTtnpeTyikqBlJOstgWFX6h+RfFFK WY4TGE4EW0ml/6HRCtmI9GXv9IjwPUfblrfQHLTACbJ8K4Cah8HK8EUVqXjVkFI+CX+b Jo8AfrBcIIIW7fthcw1HUOIJ2KuuhuQflwx5Y= MIME-Version: 1.0 Received: by 10.204.148.77 with SMTP id o13mr402869bkv.97.1323935595859; Wed, 14 Dec 2011 23:53:15 -0800 (PST) Received: by 10.204.58.209 with HTTP; Wed, 14 Dec 2011 23:53:15 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Dec 2011 08:53:15 +0100 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -4.5 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.3 (----) On 15 December 2011 07:22, Eli Zaretskii wrote: >> Date: Wed, 14 Dec 2011 21:39:28 +0100 >> From: Joakim H=E5rsman >> >> However, Emacs doesn't seem to handle the case when the keyboard >> layout contains characters not available in the ANSI code page, and >> just prints a question mark character instead. > > Yes, Emacs on Windows uses the ANSI codepage to read the keyboard > input. =A0Does it help to play with the value of keyboard-coding-system? No, changing keyboard-coding-system doesn't help, and utf-16le-dos isn't a valid setting for keyboard-coding-system anyway. >> For certain characters, >> a character that is visually similar to the actual character is >> printed instead of a question mark. For example, if I use a layout >> where AltGr+O produces U+2218 RING OPERATOR, Emacs prints U+00B0 >> DEGREE SYMBOL instead. The degree symbol is available in Windows 1252, >> the default ANSI code page on my system, but the ring operator >> isn't. > > I'm guessing that this is Windows trying to translate the characters > to the ANSI codepage behind the scenes. > >> However, if the layout maps AltGr+R to U+0220A SMALL ELEMENT OF, Emacs >> just prints a question mark, presumably because Windows 1252 doesn't >> contain a reasonable replacement for that character. > > Will inputting these characters with "C-x 8 RET 0220a RET" or "C-x 8 > RET SMALL ELEMENT OF RET" be a good enough solution for you? =A0You can > input any Unicode character by its name or codepoint using "C-x 8 RET". Using C-x 8 is too cumbersome. I guess I could write my own custom Emacs input method, but since Emacs now has good support for Unicode, it would seem easier if it handled Unicode key events from the OS correctly. >> I'd be happy to help debug this but I have no idea where to even >> start. Is there an easy way to find out if it's the C code that >> clobbers the character or if it happens in lisp for example? > > I don't think there any "clobbering". =A0Emacs deliberately converts the > Unicode characters to the current locale's ANSI codepage. =A0I think > (but I'm not sure) the reason is that Emacs cannot use UTF-16 for > keyboard input. =A0Perhaps Jason and Handa-san could comment on this. I really don't know my way around the Emacs source, but a quick look at w32_kbd_patch_key in w32inevt.c seems to indicate that Emacs really is decoding the Unicode character event correctly, both uChar.UnicodeChar and uChar.AsciiChar seem to be set correctly. /* On NT, call ToUnicode instead and then convert to the current locale's default codepage. */ if (os_subtype =3D=3D OS_NT) { WCHAR buf[128]; isdead =3D ToUnicode (event->wVirtualKeyCode, event->wVirtualScanCode= , keystate, buf, 128, 0); if (isdead > 0) { char cp[20]; int cpId; event->uChar.UnicodeChar =3D buf[isdead - 1]; GetLocaleInfo (GetThreadLocale (), LOCALE_IDEFAULTANSICODEPAGE, cp, 20); cpId =3D atoi (cp); isdead =3D WideCharToMultiByte (cpId, 0, buf, isdead, ansi_code, 4, NULL, NULL); } else isdead =3D 0; } However, this bit from w32_wnd_proc in w32fns.c looks suspicious to me: else { /* Try to handle other keystrokes by determining the base character (ie. translating the base key plus shift modifier). */ int add; KEY_EVENT_RECORD key; key.bKeyDown =3D TRUE; key.wRepeatCount =3D 1; key.wVirtualKeyCode =3D wParam; key.wVirtualScanCode =3D (lParam & 0xFF0000) >> 16; key.uChar.AsciiChar =3D 0; key.dwControlKeyState =3D modifiers; add =3D w32_kbd_patch_key (&key); /* 0 means an unrecognized keycode, negative means dead key. Ignore both. */ while (--add >=3D 0) { /* Forward asciified character sequence. */ post_character_message (hwnd, WM_CHAR, (unsigned char) key.uChar.AsciiChar, lParam, w32_get_key_modifiers (wParam, lParam)); w32_kbd_patch_key (&key); } return 0; } It looks like it's re-posting the event with just the Ascii key code, clobbering the Unicode info that's originally in wParam. Or maybe the idea is to translate characters that require multiple bytes into multiple events? From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Dec 2011 10:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: jasonr@gnu.org, 10299@debbugs.gnu.org, handa@m17n.org Reply-To: Eli Zaretskii Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132394646714337 (code B ref 10299); Thu, 15 Dec 2011 10:55:02 +0000 Received: (at 10299) by debbugs.gnu.org; 15 Dec 2011 10:54:27 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rb8xH-0003jC-5w for submit@debbugs.gnu.org; Thu, 15 Dec 2011 05:54:27 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rb8xF-0003j4-As for 10299@debbugs.gnu.org; Thu, 15 Dec 2011 05:54:26 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LW800F00RGP7600@a-mtaout21.012.net.il> for 10299@debbugs.gnu.org; Thu, 15 Dec 2011 12:52:12 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.18.12]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LW800ECYRIZHMD0@a-mtaout21.012.net.il>; Thu, 15 Dec 2011 12:52:12 +0200 (IST) Date: Thu, 15 Dec 2011 12:52:14 +0200 From: Eli Zaretskii In-reply-to: Message-id: <838vme2jkx.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Date: Thu, 15 Dec 2011 08:53:15 +0100 > From: Joakim H=E5rsman > Cc: 10299@debbugs.gnu.org, handa@m17n.org, jasonr@gnu.org >=20 > I really don't know my way around the Emacs source, but a quick loo= k > at w32_kbd_patch_key in w32inevt.c seems to indicate that Emacs rea= lly > is decoding the Unicode character event correctly, both > uChar.UnicodeChar and uChar.AsciiChar seem to be set correctly. > [...] > However, this bit from w32_wnd_proc in w32fns.c looks suspicious to= me: > [...] > It looks like it's re-posting the event with just the Ascii key cod= e, > clobbering the Unicode info that's originally in wParam. I'd begin by establishing what kind of message Emacs gets when you type a key created by MKLC. It could be WM_KEYDOWN, but it could als= o be something else, like WM_UNICHAR. Can you find that out, either with a debugger or with some other tool= ? If you can, please show the parameters of the message sent to Emacs. Then we can continue tracing the code execution from there. Note that Emacs has a separate thread that reads the Windows events, and that thread then passes the events to the main thread, where the event undergoes several levels of processing. It's a complicated issue, so we had better established from the get-go what kind of inpu= t are we processing. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Dec 2011 11:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: jasonr@gnu.org, 10299@debbugs.gnu.org, handa@m17n.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132394757115924 (code B ref 10299); Thu, 15 Dec 2011 11:13:01 +0000 Received: (at 10299) by debbugs.gnu.org; 15 Dec 2011 11:12:51 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rb9F4-00048l-Vx for submit@debbugs.gnu.org; Thu, 15 Dec 2011 06:12:51 -0500 Received: from mail-ey0-f172.google.com ([209.85.215.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rb9F2-00048e-Px for 10299@debbugs.gnu.org; Thu, 15 Dec 2011 06:12:49 -0500 Received: by eaad1 with SMTP id d1so1711123eaa.3 for <10299@debbugs.gnu.org>; Thu, 15 Dec 2011 03:11:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ldmXlosoAcrh70QOZXEkvO+wRz9IhqMSN8V59ntrBgE=; b=kpOTZINFoyw1W3OqGhk2kKuBZ0K8S7K16qxua+OkmOyn6iXoAK/LTZ6JU9iFS8CLq/ Jk37DVsZ04pV7eHaKz89cFJFkHzIzLxdAWJMjIO9/jqai6IZMOl2/KF7/IFOtEXeA83Q BT3/z0mgKlCp7CnpRDDzRbZsA/XnPC+jM16nw= MIME-Version: 1.0 Received: by 10.204.133.197 with SMTP id g5mr609793bkt.43.1323947478908; Thu, 15 Dec 2011 03:11:18 -0800 (PST) Received: by 10.204.58.209 with HTTP; Thu, 15 Dec 2011 03:11:18 -0800 (PST) In-Reply-To: <838vme2jkx.fsf@gnu.org> References: <838vme2jkx.fsf@gnu.org> Date: Thu, 15 Dec 2011 12:11:18 +0100 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -4.2 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.1 (----) Ok, I'll try to build Emacs on Windows and see if I can set a breakpoint and look at the message Emacs is getting. On 15 December 2011 11:52, Eli Zaretskii wrote: >> Date: Thu, 15 Dec 2011 08:53:15 +0100 >> From: Joakim H=E5rsman >> Cc: 10299@debbugs.gnu.org, handa@m17n.org, jasonr@gnu.org >> >> I really don't know my way around the Emacs source, but a quick look >> at w32_kbd_patch_key in w32inevt.c seems to indicate that Emacs really >> is decoding the Unicode character event correctly, both >> uChar.UnicodeChar and uChar.AsciiChar seem to be set correctly. >> [...] >> However, this bit from w32_wnd_proc in w32fns.c looks suspicious to me: >> [...] >> It looks like it's re-posting the event with just the Ascii key code, >> clobbering the Unicode info that's originally in wParam. > > I'd begin by establishing what kind of message Emacs gets when you > type a key created by MKLC. =A0It could be WM_KEYDOWN, but it could also > be something else, like WM_UNICHAR. > > Can you find that out, either with a debugger or with some other tool? > If you can, please show the parameters of the message sent to Emacs. > Then we can continue tracing the code execution from there. > > Note that Emacs has a separate thread that reads the Windows events, > and that thread then passes the events to the main thread, where the > event undergoes several levels of processing. =A0It's a complicated > issue, so we had better established from the get-go what kind of input > are we processing. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Dec 2011 13:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: jasonr@gnu.org, 10299@debbugs.gnu.org, handa@m17n.org Reply-To: Eli Zaretskii Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.1323955110571 (code B ref 10299); Thu, 15 Dec 2011 13:19:01 +0000 Received: (at 10299) by debbugs.gnu.org; 15 Dec 2011 13:18:30 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbBCf-00009A-RE for submit@debbugs.gnu.org; Thu, 15 Dec 2011 08:18:30 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbBCc-000090-S0 for 10299@debbugs.gnu.org; Thu, 15 Dec 2011 08:18:28 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LW800500Y4C8D00@a-mtaout20.012.net.il> for 10299@debbugs.gnu.org; Thu, 15 Dec 2011 15:16:55 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.54.125]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LW80051KY868810@a-mtaout20.012.net.il>; Thu, 15 Dec 2011 15:16:55 +0200 (IST) Date: Thu, 15 Dec 2011 15:16:57 +0200 From: Eli Zaretskii In-reply-to: Message-id: <831us62cvq.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <838vme2jkx.fsf@gnu.org> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Date: Thu, 15 Dec 2011 12:11:18 +0100 > From: Joakim H=E5rsman > Cc: 10299@debbugs.gnu.org, handa@m17n.org, jasonr@gnu.org >=20 > Ok, I'll try to build Emacs on Windows and see if I can set a > breakpoint and look at the message Emacs is getting. Thanks. For the record, my guess is that you will see Emacs getting a WM_CHAR messages with character codes below 256, i.e. characters encoded in the current ANSI codepage. This is because in w32fns.c:w32_init_clas= s we call the ANSI variant of RegisterClass (since UNICODE is not defined), which tells Windows that we want messages with text in the ANSI character set. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Jason Rumney Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Dec 2011 14:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 10299@debbugs.gnu.org, Joakim =?UTF-8?Q?H=C3=A5rsman?= , handa@m17n.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.13239601337978 (code B ref 10299); Thu, 15 Dec 2011 14:43:01 +0000 Received: (at 10299) by debbugs.gnu.org; 15 Dec 2011 14:42:13 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbCVf-00024c-Rx for submit@debbugs.gnu.org; Thu, 15 Dec 2011 09:42:13 -0500 Received: from mail-gy0-f172.google.com ([209.85.160.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbCVW-00024D-9b for 10299@debbugs.gnu.org; Thu, 15 Dec 2011 09:42:06 -0500 Received: by ghrr16 with SMTP id r16so1528923ghr.3 for <10299@debbugs.gnu.org>; Thu, 15 Dec 2011 06:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=YSlly5xzX6OPHZjzEix87Rg96QHAl6j2hUZI2T/Vh4U=; b=GgEUz9TNZ9j1l8ATBg8I0e6Rn7TAo/Pu3mso4atIrVpdHtF3TdHqx87ij0ltCW7+K0 rVPdxd2D0jDudCOitv+7l6pE63wWyF4AYBei2YVcrcARXBQ/Y8Brx+APq94SgAqJgVsn qWylIKabpN6ziaP+INaGuyCTYF7tbkDNTMTdg= Received: by 10.50.236.40 with SMTP id ur8mr3166978igc.91.1323960031769; Thu, 15 Dec 2011 06:40:31 -0800 (PST) Received: from home.jasonrumney.net ([180.75.128.157]) by mx.google.com with ESMTPS id py9sm10950385igc.2.2011.12.15.06.40.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Dec 2011 06:40:29 -0800 (PST) Received: by home.jasonrumney.net (Postfix, from userid 1000) id 5678DE0A; Thu, 15 Dec 2011 22:40:16 +0800 (MYT) From: Jason Rumney References: Date: Thu, 15 Dec 2011 22:40:15 +0800 In-Reply-To: (Eli Zaretskii's message of "Thu, 15 Dec 2011 01:22:11 -0500") Message-ID: <8739clgapc.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) Eli Zaretskii writes: >> Date: Wed, 14 Dec 2011 21:39:28 +0100 >> From: Joakim H=C3=A5rsman >>=20 >> However, Emacs doesn't seem to handle the case when the keyboard >> layout contains characters not available in the ANSI code page, and >> just prints a question mark character instead. > > Yes, Emacs on Windows uses the ANSI codepage to read the keyboard > input. Does it help to play with the value of keyboard-coding-system? It tries to use Unicode if the Windows input method is sending it. The problem here is that there is no standard for Windows input methods, so even the ones built into Windows act differently for different languages and for the same language across different versions of Windows. Some input methods will send WM_UNICHAR messages with the Unicode character, which can be intercepted before they are turned into question marks by Windows. These will just work with Emacs. Others will send character codes corresponding to the codepoints in the default Windows codepage for that language (regardless of your system codepage). These can be handled by changing keyboard-coding-system within Emacs. Others will not send anything useful unless your system codepage is set appropriately for the language being input. It sounds like this one may be in the third category. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Lennart Borgman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Dec 2011 15:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jason Rumney Cc: Eli Zaretskii , 10299@debbugs.gnu.org, Joakim =?UTF-8?Q?H=C3=A5rsman?= Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132396182411015 (code B ref 10299); Thu, 15 Dec 2011 15:11:01 +0000 Received: (at 10299) by debbugs.gnu.org; 15 Dec 2011 15:10:24 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbCwx-0002rc-G4 for submit@debbugs.gnu.org; Thu, 15 Dec 2011 10:10:23 -0500 Received: from mail-lpp01m010-f44.google.com ([209.85.215.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbCww-0002rV-1a for 10299@debbugs.gnu.org; Thu, 15 Dec 2011 10:10:22 -0500 Received: by laah2 with SMTP id h2so959365laa.3 for <10299@debbugs.gnu.org>; Thu, 15 Dec 2011 07:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=YLaKhZ1ziYx6lK79iipi1+YHrmrQqw/DECbkSaZNGm4=; b=hCoIH0yMVK9UKutYE1FljCopHs4X6jbxDx6WMueFO/d1T2rsAO0+EeeW+QjKKEg2sE 0Z+07FjRBJSwMz2NtwJhldtrm0LFFll9rMn/K1i26R6zCatvZ7+WHRZ7fik2l+oOGHmj Vtwr/NF6971RqxU7Le7Al4crBCt+dqz5C/mo4= Received: by 10.152.103.71 with SMTP id fu7mr3312881lab.31.1323961731123; Thu, 15 Dec 2011 07:08:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.27.104 with HTTP; Thu, 15 Dec 2011 07:08:30 -0800 (PST) In-Reply-To: <8739clgapc.fsf@gnu.org> References: <8739clgapc.fsf@gnu.org> From: Lennart Borgman Date: Thu, 15 Dec 2011 16:08:30 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) On Thu, Dec 15, 2011 at 15:40, Jason Rumney wrote: > > It tries to use Unicode if the Windows input method is sending it. =C2=A0= The > problem here is that there is no standard for Windows input methods, so > even the ones built into Windows act differently for different languages > and for the same language across different versions of Windows. > > Some input methods will send WM_UNICHAR messages with the Unicode > character, which can be intercepted before they are turned into question > marks by Windows. These will just work with Emacs. > > Others will send character codes corresponding to the codepoints in the > default Windows codepage for that language (regardless of your system > codepage). These can be handled by changing keyboard-coding-system > within Emacs. > > Others will not send anything useful unless your system codepage is set > appropriately for the language being input. > > It sounds like this one may be in the third category. Since Windows can handle this there must be a way to do it. But maybe there are no docs from MS that explains how? From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Dec 2011 15:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jason Rumney Cc: Eli Zaretskii , 10299@debbugs.gnu.org, handa@m17n.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132396370313818 (code B ref 10299); Thu, 15 Dec 2011 15:42:01 +0000 Received: (at 10299) by debbugs.gnu.org; 15 Dec 2011 15:41:43 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbDRH-0003ap-Ap for submit@debbugs.gnu.org; Thu, 15 Dec 2011 10:41:43 -0500 Received: from mail-ey0-f172.google.com ([209.85.215.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbDRD-0003ag-UJ for 10299@debbugs.gnu.org; Thu, 15 Dec 2011 10:41:40 -0500 Received: by eaad1 with SMTP id d1so1967959eaa.3 for <10299@debbugs.gnu.org>; Thu, 15 Dec 2011 07:40:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jmDlpM6q2WExSKZj/njDfLTvAeQ0572+qzvxIyT9jgo=; b=x+Rcv/UiM+YuE8UvC2/7/Lzi0mjPGKkGX9TgnjDKnc3LXpAVmjoFwLQrgRLlbZv6yr isXqh0/XNdl4PwI8SE2L0JIQLxy+r6R1xJ3PMuTXwLQqjoy7fi29s1jn57yXpzpm0oIg cEhysWdFkRWqEUbVz+/baEUYzJMQuRLX68pDI= MIME-Version: 1.0 Received: by 10.205.129.148 with SMTP id hi20mr1361442bkc.25.1323963609007; Thu, 15 Dec 2011 07:40:09 -0800 (PST) Received: by 10.204.58.209 with HTTP; Thu, 15 Dec 2011 07:40:08 -0800 (PST) In-Reply-To: <8739clgapc.fsf@gnu.org> References: <8739clgapc.fsf@gnu.org> Date: Thu, 15 Dec 2011 16:40:08 +0100 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -4.1 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.0 (----) On 15 December 2011 15:40, Jason Rumney wrote: > Eli Zaretskii writes: > >>> Date: Wed, 14 Dec 2011 21:39:28 +0100 >>> From: Joakim H=E5rsman >>> >>> However, Emacs doesn't seem to handle the case when the keyboard >>> layout contains characters not available in the ANSI code page, and >>> just prints a question mark character instead. >> >> Yes, Emacs on Windows uses the ANSI codepage to read the keyboard >> input. =A0Does it help to play with the value of keyboard-coding-system? > > It tries to use Unicode if the Windows input method is sending it. =A0The > problem here is that there is no standard for Windows input methods, so > even the ones built into Windows act differently for different languages > and for the same language across different versions of Windows. > > Some input methods will send WM_UNICHAR messages with the Unicode > character, which can be intercepted before they are turned into question > marks by Windows. These will just work with Emacs. > > Others will send character codes corresponding to the codepoints in the > default Windows codepage for that language (regardless of your system > codepage). These can be handled by changing keyboard-coding-system > within Emacs. > > Others will not send anything useful unless your system codepage is set > appropriately for the language being input. > > It sounds like this one may be in the third category. Well, the custom keyboard layout works in all other programs I've tried so Windows is certainly sending something useful to them. However, I think IMEs use a slightly different, more complex method to send input events. Emacs seems to handle IMEs better than custom keyboard layouts, with an IME you can get ungarbled Unicode characters into Emacs. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Dec 2011 17:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jason Rumney Cc: 10299@debbugs.gnu.org, joakim.harsman@gmail.com, handa@m17n.org Reply-To: Eli Zaretskii Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132397058524118 (code B ref 10299); Thu, 15 Dec 2011 17:37:02 +0000 Received: (at 10299) by debbugs.gnu.org; 15 Dec 2011 17:36:25 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbFEH-0006Gw-G2 for submit@debbugs.gnu.org; Thu, 15 Dec 2011 12:36:25 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbFEE-0006Gn-2N for 10299@debbugs.gnu.org; Thu, 15 Dec 2011 12:36:23 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LW900800A38UD00@a-mtaout20.012.net.il> for 10299@debbugs.gnu.org; Thu, 15 Dec 2011 19:34:49 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.54.125]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LW9006ZQA5ZREP0@a-mtaout20.012.net.il>; Thu, 15 Dec 2011 19:34:48 +0200 (IST) Date: Thu, 15 Dec 2011 19:34:51 +0200 From: Eli Zaretskii In-reply-to: <8739clgapc.fsf@gnu.org> Message-id: <83zket20xw.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <8739clgapc.fsf@gnu.org> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > From: Jason Rumney > Cc: Joakim H=C3=A5rsman , > 10299@debbugs.gnu.org, handa@m17n.org > Date: Thu, 15 Dec 2011 22:40:15 +0800 >=20 > > Yes, Emacs on Windows uses the ANSI codepage to read the keyboard > > input. Does it help to play with the value of keyboard-coding-sy= stem? >=20 > It tries to use Unicode if the Windows input method is sending it. But am I right that, except for perhaps IME, we mostly get WM_CHAR messages with ANSI character set, because we call the ANSI version of RegisterClass? If that is the reason, are there any complications to call RegisterClassW instead (on NT and later systems; I think Windows 9X are safer with ANSI)? > Some input methods will send WM_UNICHAR messages with the Unicode > character, which can be intercepted before they are turned into que= stion > marks by Windows. These will just work with Emacs. >=20 > Others will send character codes corresponding to the codepoints in= the > default Windows codepage for that language (regardless of your syst= em > codepage). These can be handled by changing keyboard-coding-system > within Emacs. >=20 > Others will not send anything useful unless your system codepage is= set > appropriately for the language being input. >=20 > It sounds like this one may be in the third category. I'm not sure MKLC works through IME. Do you know that for a fact? From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Dec 2011 20:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: handa@m17n.org, 10299@debbugs.gnu.org, Jason Rumney Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.13239823538810 (code B ref 10299); Thu, 15 Dec 2011 20:53:02 +0000 Received: (at 10299) by debbugs.gnu.org; 15 Dec 2011 20:52:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbII5-0002I3-1x for submit@debbugs.gnu.org; Thu, 15 Dec 2011 15:52:33 -0500 Received: from mail-ey0-f172.google.com ([209.85.215.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbII3-0002Hw-0u for 10299@debbugs.gnu.org; Thu, 15 Dec 2011 15:52:32 -0500 Received: by eaad1 with SMTP id d1so2278511eaa.3 for <10299@debbugs.gnu.org>; Thu, 15 Dec 2011 12:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=moXK86O/DhUUiod4Tc9xfeREjIxvx/ra+9tLSmMqL9M=; b=vkLsbRu1+NT9MuTmpd+UeaUIcwKxIXNapxncX+pLFixqfCos1VLi2/+wsot7IdQBIS 2oyzpNea97OMHl1J2xsVVJsTWDC7xOE+nw4KmQ5OI5ww99HRw77nbB1b0Z2ZI+tZlmry inlxl/WtKTACOK8q7wVpNYVGA9JvK7Dzh37hs= MIME-Version: 1.0 Received: by 10.205.128.12 with SMTP id hc12mr2228126bkc.133.1323982258739; Thu, 15 Dec 2011 12:50:58 -0800 (PST) Received: by 10.204.58.209 with HTTP; Thu, 15 Dec 2011 12:50:58 -0800 (PST) In-Reply-To: <83zket20xw.fsf@gnu.org> References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> Date: Thu, 15 Dec 2011 21:50:58 +0100 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.9 (---) On 15 December 2011 18:34, Eli Zaretskii wrote: >> From: Jason Rumney >> Cc: Joakim H=E5rsman , >> =A0 10299@debbugs.gnu.org, =A0handa@m17n.org >> Date: Thu, 15 Dec 2011 22:40:15 +0800 >> >> > Yes, Emacs on Windows uses the ANSI codepage to read the keyboard >> > input. =A0Does it help to play with the value of keyboard-coding-syste= m? >> >> It tries to use Unicode if the Windows input method is sending it. > > But am I right that, except for perhaps IME, we mostly get WM_CHAR > messages with ANSI character set, because we call the ANSI version of > RegisterClass? > > If that is the reason, are there any complications to call > RegisterClassW instead (on NT and later systems; I think Windows 9X > are safer with ANSI)? > >> Some input methods will send WM_UNICHAR messages with the Unicode >> character, which can be intercepted before they are turned into question >> marks by Windows. These will just work with Emacs. >> >> Others will send character codes corresponding to the codepoints in the >> default Windows codepage for that language (regardless of your system >> codepage). These can be handled by changing keyboard-coding-system >> within Emacs. >> >> Others will not send anything useful unless your system codepage is set >> appropriately for the language being input. >> >> It sounds like this one may be in the third category. > > I'm not sure MKLC works through IME. =A0Do you know that for a fact? No, I'm just guessing since Emacs has worked with Unicode IMEs I've tried in the past, but doesn't work with MKLC layouts. Instead of debating, it seems easier to just get Emacs running with a debugger and see what messages get delivered and what happens to them. Anyway, I've gotten the latest Bazaar trunk but I haven't managed to get it to build, compilation of make-docfile.c fails because it can't find config.h: gcc -I. -c -gdwarf-2 -g3 -mtune=3Dpentium4 -O2 -Demacs=3D1 -DHAVE_CON= FIG_H -I. ./lib -I../nt/inc -DHAVE_NTGUI=3D1 -DUSE_CRT_DLL=3D1 -DPURESIZE=3D5000000 -= DPURESIZE=3D5 000000 -o oo-spd/i386/make-docfile.o make-docfile.c make-docfile.c:36:20: config.h: No such file or directory make-docfile.c:79: error: syntax error before "NO_RETURN" make-docfile.c:79: warning: data definition has no type or storage class make[8]: *** [oo-spd/i386/make-docfile.o] Error 1 make[8]: Leaving directory `D:/Dev_projects/emacs/trunk/lib-src' make[7]: *** [bootstrap-gmake] Error 2 make[7]: Leaving directory `D:/Dev_projects/emacs/trunk/nt' I'm not really sure what to make of this, config.h is in trunk/src, but gcc doesn't seem to be looking there from what I can see. Are there more detailed build instructions available or is nt/INSTALL all there is? All I'm doing is cd:ing into the nt directory, running configure and then make bootstrap. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Dec 2011 21:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: handa@m17n.org, 10299@debbugs.gnu.org, Jason Rumney Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132398573413772 (code B ref 10299); Thu, 15 Dec 2011 21:49:01 +0000 Received: (at 10299) by debbugs.gnu.org; 15 Dec 2011 21:48:54 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbJAb-0003a4-LC for submit@debbugs.gnu.org; Thu, 15 Dec 2011 16:48:54 -0500 Received: from mail-ey0-f172.google.com ([209.85.215.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbJAY-0003Zw-B0 for 10299@debbugs.gnu.org; Thu, 15 Dec 2011 16:48:52 -0500 Received: by eaad1 with SMTP id d1so2320573eaa.3 for <10299@debbugs.gnu.org>; Thu, 15 Dec 2011 13:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZsDdSjMuWvkvyLDGmGVORhSltky36YZBtCuNH0qj9e8=; b=Mp0h8tdDQbSIQRuz/BcBzZcDAACTqomjLhjeoz2uU3XHjpRcgvbLVuLeOEW/3ZYATT YMvBcR2CiqhSE2xuLkdXKT8x2K4w4mvwHNjpIPWKGS33apYh0M7txeMGskOLb6q/mxBv 4P85ZXyEe2zYYA/tZPVuaVpYXawXJBhAkj9+8= MIME-Version: 1.0 Received: by 10.205.129.148 with SMTP id hi20mr2336919bkc.25.1323985637826; Thu, 15 Dec 2011 13:47:17 -0800 (PST) Received: by 10.204.58.209 with HTTP; Thu, 15 Dec 2011 13:47:17 -0800 (PST) In-Reply-To: References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> Date: Thu, 15 Dec 2011 22:47:17 +0100 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.9 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.9 (---) On 15 December 2011 21:50, Joakim H=E5rsman wrot= e: > On 15 December 2011 18:34, Eli Zaretskii wrote: >>> From: Jason Rumney >>> Cc: Joakim H=E5rsman , >>> =A0 10299@debbugs.gnu.org, =A0handa@m17n.org >>> Date: Thu, 15 Dec 2011 22:40:15 +0800 >>> >>> > Yes, Emacs on Windows uses the ANSI codepage to read the keyboard >>> > input. =A0Does it help to play with the value of keyboard-coding-syst= em? >>> >>> It tries to use Unicode if the Windows input method is sending it. >> >> But am I right that, except for perhaps IME, we mostly get WM_CHAR >> messages with ANSI character set, because we call the ANSI version of >> RegisterClass? >> >> If that is the reason, are there any complications to call >> RegisterClassW instead (on NT and later systems; I think Windows 9X >> are safer with ANSI)? >> >>> Some input methods will send WM_UNICHAR messages with the Unicode >>> character, which can be intercepted before they are turned into questio= n >>> marks by Windows. These will just work with Emacs. >>> >>> Others will send character codes corresponding to the codepoints in the >>> default Windows codepage for that language (regardless of your system >>> codepage). These can be handled by changing keyboard-coding-system >>> within Emacs. >>> >>> Others will not send anything useful unless your system codepage is set >>> appropriately for the language being input. >>> >>> It sounds like this one may be in the third category. >> >> I'm not sure MKLC works through IME. =A0Do you know that for a fact? > > No, I'm just guessing since Emacs has worked with Unicode IMEs I've > tried in the past, but doesn't work with MKLC layouts. Instead of > debating, it seems easier to just get Emacs running with a debugger > and see what messages get delivered and what happens to them. > > Anyway, I've gotten the latest Bazaar trunk but I haven't managed to > get it to build, compilation of make-docfile.c fails because it can't > find config.h: > > gcc -I. -c -gdwarf-2 -g3 =A0-mtune=3Dpentium4 -O2 =A0 =A0 =A0-Demacs=3D1 = -DHAVE_CONFIG_H -I. > ./lib -I../nt/inc -DHAVE_NTGUI=3D1 -DUSE_CRT_DLL=3D1 -DPURESIZE=3D5000000= -DPURESIZE=3D5 > 000000 -o oo-spd/i386/make-docfile.o make-docfile.c > make-docfile.c:36:20: config.h: No such file or directory > make-docfile.c:79: error: syntax error before "NO_RETURN" > make-docfile.c:79: warning: data definition has no type or storage class > make[8]: *** [oo-spd/i386/make-docfile.o] Error 1 > make[8]: Leaving directory `D:/Dev_projects/emacs/trunk/lib-src' > make[7]: *** [bootstrap-gmake] Error 2 > make[7]: Leaving directory `D:/Dev_projects/emacs/trunk/nt' > > I'm not really sure what to make of this, config.h is in trunk/src, > but gcc doesn't seem to be looking there from what I can see. Are > there more detailed build instructions available or is nt/INSTALL all > there is? > > All I'm doing is cd:ing into the nt directory, running configure and > then make bootstrap. Never mind, I got the build to work. It turns out I only got the above error the second time I ran "make bootstrap", presumably because some environment variable lingers from the first invocation and messes things up. To get the build to work I had to use a fresh shell and explicitly set SHELL=3Dcmd.exe when invoking make, then everything worked. I'll try to attach a debugger tomorrow. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Dec 2011 08:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: handa@m17n.org, 10299@debbugs.gnu.org, jasonr@gnu.org Reply-To: Eli Zaretskii Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.13240232973985 (code B ref 10299); Fri, 16 Dec 2011 08:15:02 +0000 Received: (at 10299) by debbugs.gnu.org; 16 Dec 2011 08:14:57 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbSwS-00012E-TO for submit@debbugs.gnu.org; Fri, 16 Dec 2011 03:14:57 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbSwP-000123-A0 for 10299@debbugs.gnu.org; Fri, 16 Dec 2011 03:14:55 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LWA00L00EOIQB00@a-mtaout23.012.net.il> for 10299@debbugs.gnu.org; Fri, 16 Dec 2011 10:13:17 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.54.125]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LWA00LIVEU2GD90@a-mtaout23.012.net.il>; Fri, 16 Dec 2011 10:13:15 +0200 (IST) Date: Fri, 16 Dec 2011 10:13:18 +0200 From: Eli Zaretskii In-reply-to: Message-id: <83vcph0w9t.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> X-Spam-Score: -1.8 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.8 (-) > Date: Thu, 15 Dec 2011 22:47:17 +0100 > From: Joakim H=E5rsman > Cc: Jason Rumney , 10299@debbugs.gnu.org, handa@m17= n.org >=20 > > gcc -I. -c -gdwarf-2 -g3 =A0-mtune=3Dpentium4 -O2 =A0 =A0 =A0-Dem= acs=3D1 -DHAVE_CONFIG_H -I. > > ./lib -I../nt/inc -DHAVE_NTGUI=3D1 -DUSE_CRT_DLL=3D1 -DPURESIZE= =3D5000000 -DPURESIZE=3D5 > > 000000 -o oo-spd/i386/make-docfile.o make-docfile.c > > make-docfile.c:36:20: config.h: No such file or directory > > make-docfile.c:79: error: syntax error before "NO_RETURN" > > make-docfile.c:79: warning: data definition has no type or storag= e class > > make[8]: *** [oo-spd/i386/make-docfile.o] Error 1 > > make[8]: Leaving directory `D:/Dev_projects/emacs/trunk/lib-src' > > make[7]: *** [bootstrap-gmake] Error 2 > > make[7]: Leaving directory `D:/Dev_projects/emacs/trunk/nt' > > > > I'm not really sure what to make of this, config.h is in trunk/sr= c, > > but gcc doesn't seem to be looking there from what I can see. Are > > there more detailed build instructions available or is nt/INSTALL= all > > there is? > > > > All I'm doing is cd:ing into the nt directory, running configure = and > > then make bootstrap. >=20 > Never mind, I got the build to work. >=20 > It turns out I only got the above error the second time I ran "make > bootstrap", presumably because some environment variable lingers fr= om > the first invocation and messes things up. That compilation failed because -I../src is missing from the command line: > gcc -I. -c -gdwarf-2 -g3 -mtune=3Dpentium4 -O2 -Demacs=3D1 -DHAVE_C= ONFIG_H -I../lib -I../nt/inc -DHAVE_NTGUI=3D1 -DUSE_CRT_DLL=3D1 -DPUR= ESIZE=3D5000000 -DPURESIZE=3D5000000 -o oo-spd/i386/make-docfile.o ma= ke-docfile.c I have no idea why that happened; lib-src/makefile definitely include= s "-I../src" through the LOCAL_FLAGS variable. Could it be that you somehow set LOCAL_FLAGS in the environment? In general, the compilation should never leave anything in the environment, so I don't think your explanation is quite right. Also, there's no need to "make bootstrap" twice; once you ran bootstrap once, the subsequent builds should be doe with just "make" in the nt/ subdirectory. > To get the build to work I had to use a fresh shell and explicitly = set > SHELL=3Dcmd.exe when invoking make Do you have a sh.exe somewhere on PATH? Or do you have SHELL in your environment set to something other than cmd.exe? Otherwise, there should be no need to set SHELL. Not that all this matters, now that you've succeeded to build. The only thing that does matter is that you've compiled with optimizations (which is the default), which will make it hard to examine the code under the debugger. So I suggest to reconfigure and rebuild without optimizations, like this: cd nt configure --no-opt --enable-checking make You will then have an unoptimized emacs.exe in src/oo/i386/emacs.exe. If you want it in bin/, say "make install" after the last "make". Th= e old optimized build will still be available in src/oo-spd/i386. Sorry, I should have mentioned this to begin with. And thanks for working on this. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Dec 2011 11:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: handa@m17n.org, 10299@debbugs.gnu.org, jasonr@gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132403336118489 (code B ref 10299); Fri, 16 Dec 2011 11:03:01 +0000 Received: (at 10299) by debbugs.gnu.org; 16 Dec 2011 11:02:41 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbVYm-0004oA-S6 for submit@debbugs.gnu.org; Fri, 16 Dec 2011 06:02:41 -0500 Received: from mail-ey0-f172.google.com ([209.85.215.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbVYk-0004o2-IK for 10299@debbugs.gnu.org; Fri, 16 Dec 2011 06:02:39 -0500 Received: by eaad1 with SMTP id d1so2724405eaa.3 for <10299@debbugs.gnu.org>; Fri, 16 Dec 2011 03:01:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HlDl4bl/Hicwhs9qpFrgSxLjh4ffJovWXe6yVGC9+qw=; b=YWbsr3895PQXlpe0nSMhVZfOrHkmvfRWU3qP7f41fblYFgj3h8Qc/RBPfhoijJvSNk 9EHC6XgjmXqtJiMzk4HRNrX6y9NZ3dz0R1LA9gCZnH03CN8bd1UlR44uMIKKwkzfgqHA V5aRHGNrNO90A9DQGfD9MdoaMR9ceogDFroMY= MIME-Version: 1.0 Received: by 10.205.129.148 with SMTP id hi20mr2759442bkc.25.1324033262892; Fri, 16 Dec 2011 03:01:02 -0800 (PST) Received: by 10.204.58.209 with HTTP; Fri, 16 Dec 2011 03:01:02 -0800 (PST) In-Reply-To: <83vcph0w9t.fsf@gnu.org> References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> Date: Fri, 16 Dec 2011 12:01:02 +0100 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.9 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.8 (---) On 16 December 2011 09:13, Eli Zaretskii wrote: >> Date: Thu, 15 Dec 2011 22:47:17 +0100 >> From: Joakim H=E5rsman >> Cc: Jason Rumney , 10299@debbugs.gnu.org, handa@m17n.org >> >> > gcc -I. -c -gdwarf-2 -g3 =A0-mtune=3Dpentium4 -O2 =A0 =A0 =A0-Demacs= =3D1 -DHAVE_CONFIG_H -I. >> > ./lib -I../nt/inc -DHAVE_NTGUI=3D1 -DUSE_CRT_DLL=3D1 -DPURESIZE=3D5000= 000 -DPURESIZE=3D5 >> > 000000 -o oo-spd/i386/make-docfile.o make-docfile.c >> > make-docfile.c:36:20: config.h: No such file or directory >> > make-docfile.c:79: error: syntax error before "NO_RETURN" >> > make-docfile.c:79: warning: data definition has no type or storage cla= ss >> > make[8]: *** [oo-spd/i386/make-docfile.o] Error 1 >> > make[8]: Leaving directory `D:/Dev_projects/emacs/trunk/lib-src' >> > make[7]: *** [bootstrap-gmake] Error 2 >> > make[7]: Leaving directory `D:/Dev_projects/emacs/trunk/nt' >> > >> > I'm not really sure what to make of this, config.h is in trunk/src, >> > but gcc doesn't seem to be looking there from what I can see. Are >> > there more detailed build instructions available or is nt/INSTALL all >> > there is? >> > >> > All I'm doing is cd:ing into the nt directory, running configure and >> > then make bootstrap. >> >> Never mind, I got the build to work. >> >> It turns out I only got the above error the second time I ran "make >> bootstrap", presumably because some environment variable lingers from >> the first invocation and messes things up. > > That compilation failed because -I../src is missing from the command > line: > >> gcc -I. -c -gdwarf-2 -g3 -mtune=3Dpentium4 -O2 -Demacs=3D1 -DHAVE_CONFIG= _H -I../lib -I../nt/inc -DHAVE_NTGUI=3D1 -DUSE_CRT_DLL=3D1 -DPURESIZE=3D500= 0000 -DPURESIZE=3D5000000 -o oo-spd/i386/make-docfile.o make-docfile.c > > I have no idea why that happened; lib-src/makefile definitely includes > "-I../src" through the LOCAL_FLAGS variable. =A0Could it be that you > somehow set LOCAL_FLAGS in the environment? > > In general, the compilation should never leave anything in the > environment, so I don't think your explanation is quite right. > > Also, there's no need to "make bootstrap" twice; once you ran > bootstrap once, the subsequent builds should be doe with just "make" > in the nt/ subdirectory. > >> To get the build to work I had to use a fresh shell and explicitly set >> SHELL=3Dcmd.exe when invoking make > > Do you have a sh.exe somewhere on PATH? =A0Or do you have SHELL in your > environment set to something other than cmd.exe? =A0Otherwise, there > should be no need to set SHELL. > > Not that all this matters, now that you've succeeded to build. > > The only thing that does matter is that you've compiled with > optimizations (which is the default), which will make it hard to > examine the code under the debugger. =A0So I suggest to reconfigure and > rebuild without optimizations, like this: > > =A0cd nt > =A0configure --no-opt --enable-checking > =A0make > > You will then have an unoptimized emacs.exe in src/oo/i386/emacs.exe. > If you want it in bin/, say "make install" after the last "make". =A0The > old optimized build will still be available in src/oo-spd/i386. > > Sorry, I should have mentioned this to begin with. > > And thanks for working on this. I think I have a MSYS sh.exe somewhere in my path which caused the build to fail if I didn't explicitly set SHELL. Anyway, I managed to do some debugging and your theory seems to be correct. The WM_KEYDOWN is passed to TranslateMessage which posts a WM_CHAR with a question mark, so Emacs never sees the correct Unicode character. Also, the documentation for RegisterClass at http://msdn.microsoft.com/en-us/library/windows/desktop/ms633586%28v=3Dvs.8= 5%29.aspx says: "If you register the window class by using RegisterClassA, the application tells the system that the windows of the created class expect messages with text or character parameters to use the ANSI character set; if you register it by using RegisterClassW, the application requests that the system pass text parameters of messages as Unicode." So I'll try to change to using RegisterClassW which should fix this issue but might break other stuff since more messages will deliver Unicode text then. An alternative might be to compare the result of ToUnicode and ToAscii inside WM_KEYDOWN and skip calling TranslateMessage when it will lose the correct character. I'll get back to you with the results. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Dani Moncayo Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Dec 2011 11:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: Eli Zaretskii , 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132403418819660 (code B ref 10299); Fri, 16 Dec 2011 11:17:01 +0000 Received: (at 10299) by debbugs.gnu.org; 16 Dec 2011 11:16:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbVm8-000573-3P for submit@debbugs.gnu.org; Fri, 16 Dec 2011 06:16:28 -0500 Received: from mail-gy0-f172.google.com ([209.85.160.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbVm5-00056w-W9 for 10299@debbugs.gnu.org; Fri, 16 Dec 2011 06:16:26 -0500 Received: by ghrr16 with SMTP id r16so2156395ghr.3 for <10299@debbugs.gnu.org>; Fri, 16 Dec 2011 03:14:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+HupUiwsIfG15ZK9tCOwUJM2DQK63L6lxsu2An7z4yY=; b=S+TvLLd9v68LNWIDNpDe027nVdtINEnlnDqKypaQSlJ7pDo3DYYm14jp8mDHyCccl6 gSXRH9UQAoJoIeP7326fWacqU51h1a6kHNJdzMpxsEpw/TM0lKKkJsnmhiMmE0UY8DEu hHy/lbneWsPTKdh/5GtS98BxEzM4rSSwN4UYM= MIME-Version: 1.0 Received: by 10.101.127.1 with SMTP id e1mr3335903ann.42.1324034090665; Fri, 16 Dec 2011 03:14:50 -0800 (PST) Received: by 10.236.114.168 with HTTP; Fri, 16 Dec 2011 03:14:50 -0800 (PST) In-Reply-To: References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> Date: Fri, 16 Dec 2011 12:14:50 +0100 Message-ID: From: Dani Moncayo Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -3.7 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.7 (---) > I think I have a MSYS sh.exe somewhere in my path which caused the > build to fail if I didn't explicitly set SHELL. Maybe if you try "mingw32-make" instead of "make", you will be able to build Emacs successfully (see http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00025.html) HTH. -- Dani Moncayo From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Dec 2011 11:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: handa@m17n.org, 10299@debbugs.gnu.org, jasonr@gnu.org Reply-To: Eli Zaretskii Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132403462120294 (code B ref 10299); Fri, 16 Dec 2011 11:24:02 +0000 Received: (at 10299) by debbugs.gnu.org; 16 Dec 2011 11:23:41 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbVt7-0005HE-0R for submit@debbugs.gnu.org; Fri, 16 Dec 2011 06:23:41 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbVt4-0005Gz-7e for 10299@debbugs.gnu.org; Fri, 16 Dec 2011 06:23:39 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LWA00K00NAZYB00@a-mtaout22.012.net.il> for 10299@debbugs.gnu.org; Fri, 16 Dec 2011 13:22:00 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.39.203]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LWA00IESNKLWJI0@a-mtaout22.012.net.il>; Fri, 16 Dec 2011 13:22:00 +0200 (IST) Date: Fri, 16 Dec 2011 13:22:01 +0200 From: Eli Zaretskii In-reply-to: Message-id: <83r504223q.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Date: Fri, 16 Dec 2011 12:01:02 +0100 > From: Joakim H=E5rsman > Cc: jasonr@gnu.org, 10299@debbugs.gnu.org, handa@m17n.org >=20 > So I'll try to change to using RegisterClassW which should fix this > issue but might break other stuff since more messages will deliver > Unicode text then. I think using RegisterClassW is the right way. But please pay attention to this part of w32term.c:w32_read_socket: if (msg.msg.message =3D=3D WM_UNICHAR) { inev.code =3D msg.msg.wParam; } else if (msg.msg.wParam < 256) { ... } else { /* Windows shouldn't generate WM_CHAR events above = 0xFF in non-Unicode message handlers. */ DebPrint (("Non-byte WM_CHAR: %d\n", msg.msg.wParam= )); inev.kind =3D NO_EVENT; break; } inev.kind =3D inev.code < 128 ? ASCII_KEYSTROKE_EVENT : MULTIBYTE_CHAR_KEYSTROKE_= EVENT; If Windows continues sending WM_CHAR to Emacs even if you call RegisterClassW, you will probably need to modify the "else" clause to use the characters with codepoints beyond 256, instead of throwing them away. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Dec 2011 11:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dani Moncayo Cc: 10299@debbugs.gnu.org, joakim.harsman@gmail.com Reply-To: Eli Zaretskii Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132403486420822 (code B ref 10299); Fri, 16 Dec 2011 11:28:02 +0000 Received: (at 10299) by debbugs.gnu.org; 16 Dec 2011 11:27:44 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbVx1-0005Pn-JV for submit@debbugs.gnu.org; Fri, 16 Dec 2011 06:27:44 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbVx0-0005PE-6Y for 10299@debbugs.gnu.org; Fri, 16 Dec 2011 06:27:42 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LWA00L00NLQH400@a-mtaout21.012.net.il> for 10299@debbugs.gnu.org; Fri, 16 Dec 2011 13:26:06 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.39.203]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LWA00L9JNRG6T70@a-mtaout21.012.net.il>; Fri, 16 Dec 2011 13:26:06 +0200 (IST) Date: Fri, 16 Dec 2011 13:26:08 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83obv821wv.fsf@gnu.org> References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Date: Fri, 16 Dec 2011 12:14:50 +0100 > From: Dani Moncayo > Cc: Eli Zaretskii , 10299@debbugs.gnu.org > > > I think I have a MSYS sh.exe somewhere in my path which caused the > > build to fail if I didn't explicitly set SHELL. > > Maybe if you try "mingw32-make" instead of "make", you will be able to > build Emacs successfully (see > http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00025.html) If his make.exe reacts correctly to SHELL=cmd.exe, it is most probably a MinGW Make, just renamed to make.exe. (FWIW, my MinGW compiled Make is also called make.exe.) From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Dec 2011 12:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132412645415191 (code B ref 10299); Sat, 17 Dec 2011 12:55:02 +0000 Received: (at 10299) by debbugs.gnu.org; 17 Dec 2011 12:54:14 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbtmH-0003wy-Ld for submit@debbugs.gnu.org; Sat, 17 Dec 2011 07:54:13 -0500 Received: from mail-ee0-f44.google.com ([74.125.83.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RbtmF-0003wq-DI for 10299@debbugs.gnu.org; Sat, 17 Dec 2011 07:54:12 -0500 Received: by eekc14 with SMTP id c14so2849634eek.3 for <10299@debbugs.gnu.org>; Sat, 17 Dec 2011 04:52:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fJhsYphTGfJgenRPIzNGuRppQ0hG7OgpkQuSPm+kod0=; b=sHFC9x/ZrFoUvc95Skb9fPfehn70pS/P4PmaAWD7AEkS2u0rxy9PvAPolFjSCwkoJ8 6l6VEduMOYVlIyzkU7lGoFEspHk6nQJw5HCBF8FiLZUsF/xaATaOSBw69KK3Yccmbvo5 zRaB/n0Z9MVqhPYmhyOPBmfzxDzJExoAiT83Y= MIME-Version: 1.0 Received: by 10.14.50.206 with SMTP id z54mr1225230eeb.46.1324126349834; Sat, 17 Dec 2011 04:52:29 -0800 (PST) Received: by 10.204.58.209 with HTTP; Sat, 17 Dec 2011 04:52:29 -0800 (PST) In-Reply-To: <83obv821wv.fsf@gnu.org> References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> Date: Sat, 17 Dec 2011 13:52:29 +0100 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) On 16 December 2011 12:26, Eli Zaretskii wrote: >> Date: Fri, 16 Dec 2011 12:14:50 +0100 >> From: Dani Moncayo >> Cc: Eli Zaretskii , 10299@debbugs.gnu.org >> >> > I think I have a MSYS sh.exe somewhere in my path which caused the >> > build to fail if I didn't explicitly set SHELL. >> >> Maybe if you try "mingw32-make" instead of "make", you will be able to >> build Emacs successfully (see >> http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00025.html) > > If his make.exe reacts correctly to SHELL=3Dcmd.exe, it is most probably > a MinGW Make, just renamed to make.exe. =A0(FWIW, my MinGW compiled Make > is also called make.exe.) Ok, I tried switching to RegisterClassW, but that didn't really help, after calling TranslateMessage I still got WM_CHAR with a question mark. So I tried switching to CreateWindowW and GetMessageW as well, and that did the trick. Here's my changes: D:\Dev_projects\emacs\trunk\nt>bzr diff =3D=3D=3D modified file 'src/w32fns.c' --- src/w32fns.c 2011-12-04 08:02:42 +0000 +++ src/w32fns.c 2011-12-17 11:39:10 +0000 @@ -1785,7 +1785,7 @@ static BOOL w32_init_class (HINSTANCE hinst) { - WNDCLASS wc; + WNDCLASSW wc; wc.style =3D CS_HREDRAW | CS_VREDRAW; wc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; @@ -1796,9 +1796,9 @@ wc.hCursor =3D w32_load_cursor (IDC_ARROW); wc.hbrBackground =3D NULL; /* GetStockObject (WHITE_BRUSH); */ wc.lpszMenuName =3D NULL; - wc.lpszClassName =3D EMACS_CLASS; + wc.lpszClassName =3D L"Emacs"; - return (RegisterClass (&wc)); + return (RegisterClassW (&wc)); } static HWND @@ -1853,7 +1853,7 @@ } FRAME_W32_WINDOW (f) =3D hwnd - =3D CreateWindow (EMACS_CLASS, + =3D CreateWindowW (L"Emacs", f->namebuf, f->output_data.w32->dwStyle | WS_CLIPCHILDREN, EQ (left, Qunbound) ? CW_USEDEFAULT : XINT (left), @@ -2248,7 +2248,7 @@ msh_mousewheel =3D RegisterWindowMessage (MSH_MOUSEWHEEL); - while (GetMessage (&msg, NULL, 0, 0)) + while (GetMessageW (&msg, NULL, 0, 0)) { if (msg.hwnd =3D=3D NULL) { @@ -2507,7 +2507,7 @@ message that has no particular effect. */ { int c =3D wParam; - if (isalpha (c) && wmsg.dwModifiers =3D=3D ctrl_modifier) + if (iswalpha (c) && wmsg.dwModifiers =3D=3D ctrl_modifier) c =3D make_ctrl_char (c) & 0377; if (c =3D=3D quit_char || (wmsg.dwModifiers =3D=3D 0 && I had to switch to iswalpha because isalpha segfaulted when sent values larger than 255. wParam isn't really the Unicode code point here either, it's encoded as UTF-16. With this change, Emacs no longer prints a question mark when I press the special keys, it doesn't print anything at all. I figured this is beacause wParam isn't a valid Unicode codepoint here, like it is when you get a WM_UNICHAR, so I tried a quick hack converting from UTF-16 and re-posting as a WM_UNICHAR even. I changed the handling of WM_CHAR in w32_wnd_proc: case WM_CHAR: if (wParam > 255 ) { /* Hacky conversion from UTF-16 to UCS-4. Doesn't handle surrogate pairs. */ unsigned short lo =3D wParam & 0x0000FFFF; unsigned short hi =3D (wParam & 0xFFFF0000) >> 8; wParam =3D hi | lo; W32Msg wmsg; wmsg.dwModifiers =3D 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)); This fixed it! I can now enter the characters with a custom keyboard layout so I'm happy. There's loads of bugs still (e.g. the frame title is "e" instead of "Emacs@host" because I just pass the frame's namebuf to CreateWindowW without converting it to a wide string), but at least the main issue is fixed. I guess these changes need to only happen when running on NT for Emacs to still work on Windows 95 or does Emacs use MSLU? Maybe they should depend on some lisp variable being set? Here's my changes in full so far: =3D=3D=3D modified file 'src/w32fns.c' --- src/w32fns.c 2011-12-04 08:02:42 +0000 +++ src/w32fns.c 2011-12-17 12:47:44 +0000 @@ -1785,7 +1785,7 @@ static BOOL w32_init_class (HINSTANCE hinst) { - WNDCLASS wc; + WNDCLASSW wc; wc.style =3D CS_HREDRAW | CS_VREDRAW; wc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; @@ -1796,9 +1796,9 @@ wc.hCursor =3D w32_load_cursor (IDC_ARROW); wc.hbrBackground =3D NULL; /* GetStockObject (WHITE_BRUSH); */ wc.lpszMenuName =3D NULL; - wc.lpszClassName =3D EMACS_CLASS; + wc.lpszClassName =3D L"Emacs"; - return (RegisterClass (&wc)); + return (RegisterClassW (&wc)); } static HWND @@ -1853,7 +1853,7 @@ } FRAME_W32_WINDOW (f) =3D hwnd - =3D CreateWindow (EMACS_CLASS, + =3D CreateWindowW (L"Emacs", f->namebuf, f->output_data.w32->dwStyle | WS_CLIPCHILDREN, EQ (left, Qunbound) ? CW_USEDEFAULT : XINT (left), @@ -2248,7 +2248,7 @@ msh_mousewheel =3D RegisterWindowMessage (MSH_MOUSEWHEEL); - while (GetMessage (&msg, NULL, 0, 0)) + while (GetMessageW (&msg, NULL, 0, 0)) { if (msg.hwnd =3D=3D NULL) { @@ -2507,7 +2507,7 @@ message that has no particular effect. */ { int c =3D wParam; - if (isalpha (c) && wmsg.dwModifiers =3D=3D ctrl_modifier) + if (iswalpha (c) && wmsg.dwModifiers =3D=3D ctrl_modifier) c =3D make_ctrl_char (c) & 0377; if (c =3D=3D quit_char || (wmsg.dwModifiers =3D=3D 0 && @@ -2915,8 +2915,23 @@ case WM_SYSCHAR: case WM_CHAR: - post_character_message (hwnd, msg, wParam, lParam, - w32_get_key_modifiers (wParam, lParam)); + if (wParam > 255 ) + { + /* Hacky conversion from UTF-16 to UCS-4. + Doesn't handle surrogate pairs. */ + unsigned short lo =3D wParam & 0x0000FFFF; + unsigned short hi =3D (wParam & 0xFFFF0000) >> 8; + wParam =3D hi | lo; + + W32Msg wmsg; + wmsg.dwModifiers =3D 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: From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Dec 2011 15:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: 10299@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132413551728523 (code B ref 10299); Sat, 17 Dec 2011 15:26:02 +0000 Received: (at 10299) by debbugs.gnu.org; 17 Dec 2011 15:25:17 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rbw8T-0007Pz-Cx for submit@debbugs.gnu.org; Sat, 17 Dec 2011 10:25:17 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rbw8R-0007Pq-C1 for 10299@debbugs.gnu.org; Sat, 17 Dec 2011 10:25:16 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LWC00A00TAIH300@a-mtaout20.012.net.il> for 10299@debbugs.gnu.org; Sat, 17 Dec 2011 17:23:32 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.39.203]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LWC00ANXTF7CV20@a-mtaout20.012.net.il>; Sat, 17 Dec 2011 17:23:32 +0200 (IST) Date: Sat, 17 Dec 2011 17:23:36 +0200 From: Eli Zaretskii In-reply-to: Message-id: <831us31atj.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Date: Sat, 17 Dec 2011 13:52:29 +0100 > From: Joakim H=E5rsman > Cc: 10299@debbugs.gnu.org >=20 > I had to switch to iswalpha because isalpha segfaulted when sent > values larger than 255. wParam isn't really the Unicode code point > here either, it's encoded as UTF-16. With this change, Emacs no lon= ger > prints a question mark when I press the special keys, it doesn't pr= int > anything at all. >=20 > I figured this is beacause wParam isn't a valid Unicode codepoint > here, like it is when you get a WM_UNICHAR, so I tried a quick hack > converting from UTF-16 and re-posting as a WM_UNICHAR even. I chang= ed > the handling of WM_CHAR in w32_wnd_proc: >=20 > case WM_CHAR: > if (wParam > 255 ) > { > /* Hacky conversion from UTF-16 to UCS-4. > Doesn't handle surrogate pairs. */ > unsigned short lo =3D wParam & 0x0000FFFF; > unsigned short hi =3D (wParam & 0xFFFF0000) >> 8; > wParam =3D hi | lo; >=20 > W32Msg wmsg; > wmsg.dwModifiers =3D w32_get_key_modifiers (wParam, lPara= m); > signal_user_input (); > my_post_msg (&wmsg, hwnd, WM_UNICHAR, wParam, lParam); >=20 > } > else > post_character_message (hwnd, msg, wParam, lParam, > w32_get_key_modifiers (wParam, lPar= am)); >=20 > This fixed it! I can now enter the characters with a custom keyboar= d > layout so I'm happy. 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 MKL= C are outside the Unicode BMP, i.e. larger than 65535? If so, what cod= e points are they? > There's loads of bugs still (e.g. the frame title > is "e" instead of "Emacs@host" because I just pass the frame's name= buf > to CreateWindowW without converting it to a wide string), but at le= ast > the main issue is fixed. If at all possible, I'd like to keep the use of wide APIs to the absolute minimum, because: > I guess these changes need to only happen when running on NT for Em= acs > to still work on Windows 95 or does Emacs use MSLU? We do use MSLU on Windows 9X (because the display routines need that). However, given that none of the developers has easy access to a 9X machine, it is very easy to break Emacs on 9X by excess usage of wide APIs. In fact, all versions of Emacs 23 didn't work on Windows 9X and only recently we were lucky enough to find a 9X user who helpe= d us debug the problems and fix them. So if possible, could you perhaps try finding out why you didn't get UTF-16 codepoints without CreateWindowW and GetMessageW? Maybe it's TranslateMessage that causes that, and the original message Emacs get= s is okay? > Maybe they should depend on some lisp variable being set? Probably just on the value of os_subtype. > Here's my changes in full so far: Thanks. This will probably need to wait until after v24.1 is released. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 18 Dec 2011 18:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: 10299@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132423221310267 (code B ref 10299); Sun, 18 Dec 2011 18:17:01 +0000 Received: (at 10299) by debbugs.gnu.org; 18 Dec 2011 18:16:53 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RcLI4-0002fY-Om for submit@debbugs.gnu.org; Sun, 18 Dec 2011 13:16:52 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RcLI1-0002fP-Nv for 10299@debbugs.gnu.org; Sun, 18 Dec 2011 13:16:51 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LWE00A00VPPW800@a-mtaout21.012.net.il> for 10299@debbugs.gnu.org; Sun, 18 Dec 2011 20:13:46 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.39.203]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LWE00A45VYWLYD0@a-mtaout21.012.net.il>; Sun, 18 Dec 2011 20:13:46 +0200 (IST) Date: Sun, 18 Dec 2011 20:13:50 +0200 From: Eli Zaretskii In-reply-to: Message-id: <83pqflzr1d.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Date: Sun, 18 Dec 2011 18:31:55 +0100 > From: Joakim H=E5rsman >=20 > > That's good news. =A0However, I'm puzzled: are you saying that th= e code > > points passed by Windows to Emacs for the characters generated by= MKLC > > are outside the Unicode BMP, i.e. larger than 65535? =A0If so, wh= at code > > points are they? >=20 > No, none of the characters I needed are outside the BMP. >=20 > 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 unsu= re > if it's TranslateMessage that translates the key press to a questio= n > 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. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Dec 2011 10:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.1324291610490 (code B ref 10299); Mon, 19 Dec 2011 10:47:02 +0000 Received: (at 10299) by debbugs.gnu.org; 19 Dec 2011 10:46:50 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rcak6-00007q-4f for submit@debbugs.gnu.org; Mon, 19 Dec 2011 05:46:50 -0500 Received: from mail-ey0-f172.google.com ([209.85.215.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rcak4-00007i-BZ for 10299@debbugs.gnu.org; Mon, 19 Dec 2011 05:46:49 -0500 Received: by eaad1 with SMTP id d1so4466084eaa.3 for <10299@debbugs.gnu.org>; Mon, 19 Dec 2011 02:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=m2bsXyW4o3e94nFQ9uSxlgoQ4Ey/3VQe/0r8rG+9U+0=; b=qHnZdvoDJ3El/KNK/4NclSHHn0PmJmJMLCFaI7hCra2LJCgDPmOuKNcKaPfvWBBtf0 7EVjylr0rhOcNYM7y8ZgsiHaeCUfSzQT0+laCR5/tH01+oxVsAzh2xUvy682cnZ9kClE TOA/Isz5k1SzFIpssmHKoWXgIqYVAogGBpoWQ= MIME-Version: 1.0 Received: by 10.205.128.12 with SMTP id hc12mr1156516bkc.133.1324291495428; Mon, 19 Dec 2011 02:44:55 -0800 (PST) Received: by 10.204.58.209 with HTTP; Mon, 19 Dec 2011 02:44:55 -0800 (PST) In-Reply-To: <83pqflzr1d.fsf@gnu.org> References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> Date: Mon, 19 Dec 2011 11:44:55 +0100 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.8 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.8 (---) On 18 December 2011 19:13, Eli Zaretskii wrote: >> Date: Sun, 18 Dec 2011 18:31:55 +0100 >> From: Joakim H=E5rsman >> >> > That's good news. =A0However, I'm puzzled: are you saying that the cod= e >> > points passed by Windows to Emacs for the characters generated by MKLC >> > are outside the Unicode BMP, i.e. larger than 65535? =A0If so, what co= de >> > 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. =A0What 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? >> 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. =A0I.e., it means that Windows > thought the program asked for ANSI encoded characters. =A0So 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. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Lennart Borgman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Dec 2011 11:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: Eli Zaretskii , 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.13242925351847 (code B ref 10299); Mon, 19 Dec 2011 11:03:02 +0000 Received: (at 10299) by debbugs.gnu.org; 19 Dec 2011 11:02:15 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rcaz1-0000Tj-1G for submit@debbugs.gnu.org; Mon, 19 Dec 2011 06:02:15 -0500 Received: from mail-lpp01m010-f44.google.com ([209.85.215.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rcayw-0000TX-9G for 10299@debbugs.gnu.org; Mon, 19 Dec 2011 06:02:12 -0500 Received: by laah2 with SMTP id h2so2116778laa.3 for <10299@debbugs.gnu.org>; Mon, 19 Dec 2011 03:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=MNtrinAG3R85+kC6F0SSJWpvjHjLw4vqOysV9t8kT8s=; b=Wt8VzdW+idJXftKWiXSLltqYI9MSL0VRfjnJGZv+riUqoBuoXOiEC/Pb1GFaGBRWV/ icil7tDC1Cp1gCSN0m5iMVjuu3fkQBOWuRcd9fqjMqQXDCiudSqwFBv9Ee4AkTz3m56b Il8u6lAfqG0rh0JMmqnH+U0JC6LWHk4dh41Eg= Received: by 10.152.104.6 with SMTP id ga6mr15546963lab.45.1324292417166; Mon, 19 Dec 2011 03:00:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.27.104 with HTTP; Mon, 19 Dec 2011 02:59:57 -0800 (PST) In-Reply-To: References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> From: Lennart Borgman Date: Mon, 19 Dec 2011 11:59:57 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) On Mon, Dec 19, 2011 at 11:44, Joakim H=C3=A5rsman wrote: > On 18 December 2011 19:13, Eli Zaretskii wrote: >>> Date: Sun, 18 Dec 2011 18:31:55 +0100 >>> From: Joakim H=C3=A5rsman >>> >>> > That's good news. =C2=A0However, I'm puzzled: are you saying that the= code >>> > points passed by Windows to Emacs for the characters generated by MKL= C >>> > are outside the Unicode BMP, i.e. larger than 65535? =C2=A0If so, wha= t 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. =C2=A0What 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? Se= e http://blogs.msdn.com/b/michkap/archive/2007/03/25/1945659.aspx From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Dec 2011 11:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lennart Borgman Cc: Eli Zaretskii , 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.13242928032243 (code B ref 10299); Mon, 19 Dec 2011 11:07:01 +0000 Received: (at 10299) by debbugs.gnu.org; 19 Dec 2011 11:06:43 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rcb3K-0000a7-G7 for submit@debbugs.gnu.org; Mon, 19 Dec 2011 06:06:43 -0500 Received: from mail-ey0-f172.google.com ([209.85.215.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rcb3H-0000a1-SJ for 10299@debbugs.gnu.org; Mon, 19 Dec 2011 06:06:40 -0500 Received: by eaad1 with SMTP id d1so4480190eaa.3 for <10299@debbugs.gnu.org>; Mon, 19 Dec 2011 03:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=iMvCNNJqPtvO8M0xdhPhuaVTwt36ZcDiHudpcLIUNuE=; b=sBOHEB3/OuTNc/mr8pk9obo9qvRoOiPCp1elEvvQBzW2xrPHk2BU4NNqpBFpUnBBJT RAUQM2+CG5F1syP8q5jiprSbpwY3lQSRypsQsUmDUS8yCBFu56YWxqQ0VrDq04k/Rezv 70vEn0yX3rEAahL/2Nbh2BNIE1gmd62AA4Onk= MIME-Version: 1.0 Received: by 10.204.128.130 with SMTP id k2mr1174893bks.7.1324292687058; Mon, 19 Dec 2011 03:04:47 -0800 (PST) Received: by 10.204.58.209 with HTTP; Mon, 19 Dec 2011 03:04:46 -0800 (PST) In-Reply-To: References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> Date: Mon, 19 Dec 2011 12:04:46 +0100 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.8 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.8 (---) On 19 December 2011 11:59, Lennart Borgman wrot= e: > On Mon, Dec 19, 2011 at 11:44, Joakim H=E5rsman wrote: >> On 18 December 2011 19:13, Eli Zaretskii wrote: >>>> Date: Sun, 18 Dec 2011 18:31:55 +0100 >>>> From: Joakim H=E5rsman >>>> >>>> > That's good news. =A0However, I'm puzzled: are you saying that the c= ode >>>> > points passed by Windows to Emacs for the characters generated by MK= LC >>>> > are outside the Unicode BMP, i.e. larger than 65535? =A0If 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. =A0What 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. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Lennart Borgman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Dec 2011 11:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: Eli Zaretskii , 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.13242936063399 (code B ref 10299); Mon, 19 Dec 2011 11:21:02 +0000 Received: (at 10299) by debbugs.gnu.org; 19 Dec 2011 11:20:06 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RcbGI-0000sm-JC for submit@debbugs.gnu.org; Mon, 19 Dec 2011 06:20:06 -0500 Received: from mail-lpp01m010-f44.google.com ([209.85.215.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RcbGG-0000se-43 for 10299@debbugs.gnu.org; Mon, 19 Dec 2011 06:20:05 -0500 Received: by laah2 with SMTP id h2so2121779laa.3 for <10299@debbugs.gnu.org>; Mon, 19 Dec 2011 03:18:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=CrchkFCzfli/yiojsRyv9GGxcpVhe97bwFSnRbANUNc=; b=RjS41F87TS63MgiKXzh9XYQZ8+rhdM9v8azNQdzvqelKu7IH+tXzKI5BGxQDZOusFh 31+hWavDg2uDrsrVeO4dlwHa6Ih4bTtbx8ueqtU3m98VLNAVqQhojwwdiNy48xArpKrB wIZUP2FCqcoRCRo3iBF7M8d6D9lyLJJ79uoHE= Received: by 10.152.133.70 with SMTP id pa6mr2793866lab.0.1324293491110; Mon, 19 Dec 2011 03:18:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.27.104 with HTTP; Mon, 19 Dec 2011 03:17:50 -0800 (PST) In-Reply-To: References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> From: Lennart Borgman Date: Mon, 19 Dec 2011 12:17:50 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) On Mon, Dec 19, 2011 at 12:04, Joakim H=C3=A5rsman wrote: > On 19 December 2011 11:59, Lennart Borgman wr= ote: >> On Mon, Dec 19, 2011 at 11:44, Joakim H=C3=A5rsman wrote: >>> On 18 December 2011 19:13, Eli Zaretskii wrote: >>>>> Date: Sun, 18 Dec 2011 18:31:55 +0100 >>>>> From: Joakim H=C3=A5rsman >>>>> >>>>> > That's good news. =C2=A0However, I'm puzzled: are you saying that t= he code >>>>> > points passed by Windows to Emacs for the characters generated by M= KLC >>>>> > are outside the Unicode BMP, i.e. larger than 65535? =C2=A0If so, w= hat 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. =C2=A0What 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? From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Dec 2011 11:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lennart Borgman Cc: Eli Zaretskii , "10299@debbugs.gnu.org" <10299@debbugs.gnu.org> Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.13242956106485 (code B ref 10299); Mon, 19 Dec 2011 11:54:02 +0000 Received: (at 10299) by debbugs.gnu.org; 19 Dec 2011 11:53:30 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rcbmb-0001gY-O6 for submit@debbugs.gnu.org; Mon, 19 Dec 2011 06:53:30 -0500 Received: from mail-lpp01m010-f44.google.com ([209.85.215.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RcbmY-0001gP-Hy for 10299@debbugs.gnu.org; Mon, 19 Dec 2011 06:53:27 -0500 Received: by laah2 with SMTP id h2so2131064laa.3 for <10299@debbugs.gnu.org>; Mon, 19 Dec 2011 03:51:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:references:from:content-transfer-encoding:content-type :in-reply-to:message-id:date:cc:to:mime-version:x-mailer; bh=IqE6v4xtWyzsQ6dcPO5M8SmIQHhltDUOPnVxZZkwzsc=; b=BtDFb3Bc5i7GzVH4iFJbNc8x03+/RLm8fKgvcRXmeNW4GaYyrJ1FbbR9M4LLLyuTV0 o/m5FD9vh0qWyy2aa+3p5Z9ow0vXD6Eqz6yO4o+9RpT0UClFT+NxLKIzaQsmIOsQU1uv r24IukgMECyAvckzEPa1axj1Jzpfl3O+LK4dI= Received: by 10.152.125.196 with SMTP id ms4mr15875941lab.50.1324295492063; Mon, 19 Dec 2011 03:51:32 -0800 (PST) Received: from [2.64.252.194] (2.64.252.194.mobile.tre.se. [2.64.252.194]) by mx.google.com with ESMTPS id jn4sm16690681lab.16.2011.12.19.03.51.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Dec 2011 03:51:31 -0800 (PST) References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In-Reply-To: Message-Id: <55499788-D3D5-46D6-810E-27884E712125@gmail.com> Date: Mon, 19 Dec 2011 12:50:28 +0100 Mime-Version: 1.0 (iPhone Mail 8L1) X-Mailer: iPhone Mail (8L1) X-Spam-Score: -2.2 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.2 (--) I'm not the right person to ask, but presumably to remain compatible with Wi= ndows 95. Not all wide/Unicode apis are available there.=20 19 dec 2011 kl. 12:17 skrev Lennart Borgman : > On Mon, Dec 19, 2011 at 12:04, Joakim H=C3=A5rsman wrote: >> On 19 December 2011 11:59, Lennart Borgman wr= ote: >>> On Mon, Dec 19, 2011 at 11:44, Joakim H=C3=A5rsman wrote: >>>> On 18 December 2011 19:13, Eli Zaretskii wrote: >>>>>> Date: Sun, 18 Dec 2011 18:31:55 +0100 >>>>>> From: Joakim H=C3=A5rsman >>>>>>=20 >>>>>>> That's good news. However, I'm puzzled: are you saying that the cod= e >>>>>>> points passed by Windows to Emacs for the characters generated by MK= LC >>>>>>> are outside the Unicode BMP, i.e. larger than 65535? If so, what co= de >>>>>>> points are they? >>>>>>=20 >>>>>> No, none of the characters I needed are outside the BMP. >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> ??? 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? >>>>=20 >>>> 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. >>>>=20 >>>> =46rom 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? >>>=20 >>> Maybe Emacs on windows still is using the ANSI version of DefWindowProc?= See >>>=20 >>> http://blogs.msdn.com/b/michkap/archive/2007/03/25/1945659.aspx >>=20 >> 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. >=20 > Strange. What is the reason Emacs is still using the ANSI version? > Maybe a mix of ANSI and UNICODE versions gives strange results? From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Jason Rumney Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Dec 2011 13:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 10299@debbugs.gnu.org, Joakim =?UTF-8?Q?H=C3=A5rsman?= Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132430164317850 (code B ref 10299); Mon, 19 Dec 2011 13:35:02 +0000 Received: (at 10299) by debbugs.gnu.org; 19 Dec 2011 13:34:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RcdLu-0004dr-ST for submit@debbugs.gnu.org; Mon, 19 Dec 2011 08:34:03 -0500 Received: from mail-iy0-f172.google.com ([209.85.210.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RcdLs-0004dS-WC for 10299@debbugs.gnu.org; Mon, 19 Dec 2011 08:34:01 -0500 Received: by iaen33 with SMTP id n33so122913iae.3 for <10299@debbugs.gnu.org>; Mon, 19 Dec 2011 05:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=mYpQLlvA1m9zcw9bSMZhsMuvAsOIGOjuTKSIgZXb/gw=; b=HeGgxG0Ykn2FPTli8RRuVBehbnh/4LEIg4ITNjuuY25s3dH5hLgkEFr1J4OoJ1/ARW y5iCuqXtatqeWZHxPaeJKaSq0nf2U38NX58PKXimeJo80BknkmuT0FUEJ13AMtwS7CPa oBw9vtsSZExvywdqMfC8V65g5qika5TyZGO8s= Received: by 10.50.45.195 with SMTP id p3mr14144679igm.6.1324301527812; Mon, 19 Dec 2011 05:32:07 -0800 (PST) Received: from home.jasonrumney.net ([180.75.101.224]) by mx.google.com with ESMTPS id d19sm67751487ibh.8.2011.12.19.05.32.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Dec 2011 05:32:06 -0800 (PST) Received: by home.jasonrumney.net (Postfix, from userid 1000) id EBF19151C; Mon, 19 Dec 2011 21:31:58 +0800 (MYT) From: Jason Rumney References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> Date: Mon, 19 Dec 2011 21:31:58 +0800 In-Reply-To: <83pqflzr1d.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 18 Dec 2011 20:13:50 +0200") Message-ID: <877h1swuup.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) Eli Zaretskii writes: >> Date: Sun, 18 Dec 2011 18:31:55 +0100 >> From: Joakim H=C3=A5rsman >> 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? It looks like there is an endianness mismatch somewhere. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Dec 2011 21:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132441593729287 (code B ref 10299); Tue, 20 Dec 2011 21:19:01 +0000 Received: (at 10299) by debbugs.gnu.org; 20 Dec 2011 21:18:57 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rd75N-0007cK-02 for submit@debbugs.gnu.org; Tue, 20 Dec 2011 16:18:57 -0500 Received: from mail-ey0-f172.google.com ([209.85.215.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rd75K-0007cC-6S for 10299@debbugs.gnu.org; Tue, 20 Dec 2011 16:18:55 -0500 Received: by eaad1 with SMTP id d1so5855051eaa.3 for <10299@debbugs.gnu.org>; Tue, 20 Dec 2011 13:16:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qG3cx7yvwbAeGm+CeyJV/rhdyqIFzlK2VoZDgmngwcE=; b=hRZZTfoCPAi8Ff3Sy6NYblKQ7AFV83wUWyVge79zO5TXcHoR6SqHlcRTIrjw5+V8Ak p0JDTFbsaG9NCNBNfCSPXZd96O4VUZdFbpxiYXkU47O6Kyy5/b71RrBIwXH6Tv2dM+H8 7B4o2gUjasG9g2tIi1HaHWLC3sTj0bksgvxaE= MIME-Version: 1.0 Received: by 10.204.155.76 with SMTP id r12mr1391936bkw.115.1324415813350; Tue, 20 Dec 2011 13:16:53 -0800 (PST) Received: by 10.204.58.209 with HTTP; Tue, 20 Dec 2011 13:16:53 -0800 (PST) In-Reply-To: <83pqflzr1d.fsf@gnu.org> References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> Date: Tue, 20 Dec 2011 22:16:53 +0100 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.8 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.8 (---) On 18 December 2011 19:13, Eli Zaretskii wrote: >> Date: Sun, 18 Dec 2011 18:31:55 +0100 >> From: Joakim H=E5rsman >> >> > That's good news. =A0However, I'm puzzled: are you saying that the cod= e >> > points passed by Windows to Emacs for the characters generated by MKLC >> > are outside the Unicode BMP, i.e. larger than 65535? =A0If so, what co= de >> > 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. =A0What 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. =A0I.e., it means that Windows > thought the program asked for ANSI encoded characters. =A0So 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: =3D=3D=3D 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 =3D ENCODE_SYSTEM (name); + name =3D 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 =3D 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 =3D CS_HREDRAW | CS_VREDRAW; wc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; @@ -1796,9 +1796,9 @@ wc.hCursor =3D w32_load_cursor (IDC_ARROW); wc.hbrBackground =3D NULL; /* GetStockObject (WHITE_BRUSH); */ wc.lpszMenuName =3D NULL; - wc.lpszClassName =3D EMACS_CLASS; + wc.lpszClassName =3D L"Emacs"; - return (RegisterClass (&wc)); + return (RegisterClassW (&wc)); } static HWND @@ -2248,7 +2248,7 @@ msh_mousewheel =3D RegisterWindowMessage (MSH_MOUSEWHEEL); - while (GetMessage (&msg, NULL, 0, 0)) + while (GetMessageW (&msg, NULL, 0, 0)) { if (msg.hwnd =3D=3D 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 =3D wParam & 0x0000FFFF; + unsigned short hi =3D (wParam & 0xFFFF0000) >> 8; + wParam =3D hi | lo; + + W32Msg wmsg; + wmsg.dwModifiers =3D 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 =3D intern_c_string ("utf-16le-dos"); name =3D 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. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jan 2012 16:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.13265593126232 (code B ref 10299); Sat, 14 Jan 2012 16:42:01 +0000 Received: (at 10299) by debbugs.gnu.org; 14 Jan 2012 16:41:52 +0000 Received: from localhost ([127.0.0.1]:57506 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rm6fv-0001cT-1c for submit@debbugs.gnu.org; Sat, 14 Jan 2012 11:41:51 -0500 Received: from mail-bk0-f44.google.com ([209.85.214.44]:63620) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rm6ff-0001c7-SO for 10299@debbugs.gnu.org; Sat, 14 Jan 2012 11:41:49 -0500 Received: by bkwq16 with SMTP id q16so2710616bkw.3 for <10299@debbugs.gnu.org>; Sat, 14 Jan 2012 08:40:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RbDn1mLGxa0k9D7J4uOVchaISkBpdmO2cdwSF/AzhGE=; b=FXDM/8kME9vuDp+UGvRathzHHAaCh4lvHbLOL8SJwbaa3TQVD7OHiU8+ewZWr1bPP2 Jg4HuACTWIMlQXF5OrWC8G6UpoAicYqG5BglhVkawVjZfIj9dqmTgfnYBe+DuYkp74MX yUPocs1U8jQu32Jf9/KsdrgcAC4Vcu5ffj0LE= MIME-Version: 1.0 Received: by 10.204.156.83 with SMTP id v19mr2306556bkw.40.1326559251436; Sat, 14 Jan 2012 08:40:51 -0800 (PST) Received: by 10.205.128.17 with HTTP; Sat, 14 Jan 2012 08:40:51 -0800 (PST) In-Reply-To: References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> Date: Sat, 14 Jan 2012 17:40:51 +0100 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) 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. =3D=3D=3D 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 =3D ENCODE_SYSTEM (name); - + name =3D ENCODE_SYSTEM (name); + BLOCK_INPUT; - SetWindowText (FRAME_W32_WINDOW (f), SDATA (name)); + if (os_subtype =3D=3D OS_NT) + SetWindowTextW (FRAME_W32_WINDOW (f), SDATA (name)); + else + SetWindowText (FRAME_W32_WINDOW (f), SDATA (name)); UNBLOCK_INPUT; } } @@ -1746,7 +1749,10 @@ name =3D ENCODE_SYSTEM (name); BLOCK_INPUT; - SetWindowText (FRAME_W32_WINDOW (f), SDATA (name)); + if (os_subtype =3D=3D 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 =3D CS_HREDRAW | CS_VREDRAW; - wc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; - wc.cbClsExtra =3D 0; - wc.cbWndExtra =3D WND_EXTRA_BYTES; - wc.hInstance =3D hinst; - wc.hIcon =3D LoadIcon (hinst, EMACS_CLASS); - wc.hCursor =3D w32_load_cursor (IDC_ARROW); - wc.hbrBackground =3D NULL; /* GetStockObject (WHITE_BRUSH); */ - wc.lpszMenuName =3D NULL; - wc.lpszClassName =3D EMACS_CLASS; - - return (RegisterClass (&wc)); + WNDCLASSW uwc; + WNDCLASS wc; + + if (os_subtype =3D=3D OS_NT) + { + uwc.style =3D CS_HREDRAW | CS_VREDRAW; + uwc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; + uwc.cbClsExtra =3D 0; + uwc.cbWndExtra =3D WND_EXTRA_BYTES; + uwc.hInstance =3D hinst; + uwc.hIcon =3D LoadIcon (hinst, EMACS_CLASS); + uwc.hCursor =3D w32_load_cursor (IDC_ARROW); + uwc.hbrBackground =3D NULL; /* GetStockObject (WHITE_BRUSH); */ + uwc.lpszMenuName =3D NULL; + uwc.lpszClassName =3D L"Emacs"; + + return (RegisterClassW (&uwc)); + } + else + { + wc.style =3D CS_HREDRAW | CS_VREDRAW; + wc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; + wc.cbClsExtra =3D 0; + wc.cbWndExtra =3D WND_EXTRA_BYTES; + wc.hInstance =3D hinst; + wc.hIcon =3D LoadIcon (hinst, EMACS_CLASS); + wc.hCursor =3D w32_load_cursor (IDC_ARROW); + wc.hbrBackground =3D NULL; /* GetStockObject (WHITE_BRUSH); */ + wc.lpszMenuName =3D NULL; + wc.lpszClassName =3D EMACS_CLASS; + + return (RegisterClass (&wc)); + } } static HWND @@ -2248,8 +2273,16 @@ msh_mousewheel =3D RegisterWindowMessage (MSH_MOUSEWHEEL); - while (GetMessage (&msg, NULL, 0, 0)) + while (1) { + if (os_subtype =3D=3D OS_NT) + result =3D GetMessageW (&msg, NULL, 0, 0); + else + result =3D GetMessage (&msg, NULL, 0, 0); + + if (!result) + break; + if (msg.hwnd =3D=3D 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 =3D wParam & 0x0000FFFF; + unsigned short hi =3D (wParam & 0xFFFF0000) >> 8; + wParam =3D hi | lo; + + W32Msg wmsg; + wmsg.dwModifiers =3D 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=E5rsman wrot= e: > On 18 December 2011 19:13, Eli Zaretskii wrote: >>> Date: Sun, 18 Dec 2011 18:31:55 +0100 >>> From: Joakim H=E5rsman >>> >>> > That's good news. =A0However, I'm puzzled: are you saying that the co= de >>> > points passed by Windows to Emacs for the characters generated by MKL= C >>> > are outside the Unicode BMP, i.e. larger than 65535? =A0If so, what c= ode >>> > 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. =A0What 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. =A0I.e., it means that Windows >> thought the program asked for ANSI encoded characters. =A0So 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: > > =3D=3D=3D modified file 'src/w32fns.c' > --- src/w32fns.c =A0 =A0 =A0 =A02011-12-04 08:02:42 +0000 > +++ src/w32fns.c =A0 =A0 =A0 =A02011-12-20 20:46:40 +0000 > @@ -1697,10 +1697,10 @@ > =A0 if (FRAME_W32_WINDOW (f)) > =A0 =A0 { > =A0 =A0 =A0 if (STRING_MULTIBYTE (name)) > - =A0 =A0 =A0 name =3D ENCODE_SYSTEM (name); > + =A0 =A0 =A0 =A0name =3D ENCODE_SYSTEM (name); > > =A0 =A0 =A0 BLOCK_INPUT; > - =A0 =A0 =A0SetWindowText (FRAME_W32_WINDOW (f), SDATA (name)); > + =A0 =A0 =A0SetWindowTextW (FRAME_W32_WINDOW (f), SDATA (name)); > =A0 =A0 =A0 UNBLOCK_INPUT; > =A0 =A0 } > =A0} > @@ -1746,7 +1746,7 @@ > =A0 =A0 =A0 =A0name =3D ENCODE_SYSTEM (name); > > =A0 =A0 =A0 BLOCK_INPUT; > - =A0 =A0 =A0SetWindowText (FRAME_W32_WINDOW (f), SDATA (name)); > + =A0 =A0 =A0SetWindowTextW (FRAME_W32_WINDOW (f), SDATA (name)); > =A0 =A0 =A0 UNBLOCK_INPUT; > =A0 =A0 } > =A0} > @@ -1785,7 +1785,7 @@ > =A0static BOOL > =A0w32_init_class (HINSTANCE hinst) > =A0{ > - =A0WNDCLASS wc; > + =A0WNDCLASSW wc; > > =A0 wc.style =3D CS_HREDRAW | CS_VREDRAW; > =A0 wc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; > @@ -1796,9 +1796,9 @@ > =A0 wc.hCursor =3D w32_load_cursor (IDC_ARROW); > =A0 wc.hbrBackground =3D NULL; /* GetStockObject (WHITE_BRUSH); =A0*/ > =A0 wc.lpszMenuName =3D NULL; > - =A0wc.lpszClassName =3D EMACS_CLASS; > + =A0wc.lpszClassName =3D L"Emacs"; > > - =A0return (RegisterClass (&wc)); > + =A0return (RegisterClassW (&wc)); > =A0} > > =A0static HWND > @@ -2248,7 +2248,7 @@ > > =A0 msh_mousewheel =3D RegisterWindowMessage (MSH_MOUSEWHEEL); > > - =A0while (GetMessage (&msg, NULL, 0, 0)) > + =A0while (GetMessageW (&msg, NULL, 0, 0)) > =A0 =A0 { > =A0 =A0 =A0 if (msg.hwnd =3D=3D NULL) > =A0 =A0 =A0 =A0{ > @@ -2915,8 +2915,21 @@ > > =A0 =A0 case WM_SYSCHAR: > =A0 =A0 case WM_CHAR: > - =A0 =A0 =A0post_character_message (hwnd, msg, wParam, lParam, > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 w32_get_key_mod= ifiers (wParam, lParam)); > + =A0 =A0 =A0if (wParam > 255 ) > + =A0 =A0 =A0 =A0{ > + =A0 =A0 =A0 =A0 =A0unsigned short lo =3D wParam & 0x0000FFFF; > + =A0 =A0 =A0 =A0 =A0unsigned short hi =3D (wParam & 0xFFFF0000) >> 8; > + =A0 =A0 =A0 =A0 =A0wParam =A0=3D hi | lo; > + > + =A0 =A0 =A0 =A0 =A0W32Msg wmsg; > + =A0 =A0 =A0 =A0 =A0wmsg.dwModifiers =3D w32_get_key_modifiers (wParam, = lParam); > + =A0 =A0 =A0 =A0 =A0signal_user_input (); > + =A0 =A0 =A0 =A0 =A0my_post_msg (&wmsg, hwnd, WM_UNICHAR, wParam, lParam= ); > + > + =A0 =A0 =A0 =A0} > + =A0 =A0 =A0else > + =A0 =A0 =A0 =A0post_character_message (hwnd, msg, wParam, lParam, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0w32_get_= key_modifiers (wParam, lParam)); > =A0 =A0 =A0 break; > > =A0 =A0 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 =3D intern_c_string ("utf-16le-dos"); > name =3D 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. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Jan 2012 14:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: Eli Zaretskii , 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132672265429130 (code B ref 10299); Mon, 16 Jan 2012 14:05:02 +0000 Received: (at 10299) by debbugs.gnu.org; 16 Jan 2012 14:04:14 +0000 Received: from localhost ([127.0.0.1]:59862 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RmnAT-0007Zn-SC for submit@debbugs.gnu.org; Mon, 16 Jan 2012 09:04:14 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:24799) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RmnAS-0007Zg-Hx for 10299@debbugs.gnu.org; Mon, 16 Jan 2012 09:04:12 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJotFE9FxKkV/2dsb2JhbABCqweBJYEKgQaBcgEBBVYjEAs0EhQYDSS9WoldAgEBCAIMEQMJAQEGAQUeCgQBAgEBCAEBAQECgngBBgIDBwEEAQEBAYQNBIg7mmOEUg X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="156987134" Received: from 69-196-169-21.dsl.teksavvy.com (HELO ceviche.home) ([69.196.169.21]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 16 Jan 2012 09:03:17 -0500 Received: by ceviche.home (Postfix, from userid 20848) id 433DB6610D; Mon, 16 Jan 2012 09:03:17 -0500 (EST) From: Stefan Monnier Message-ID: References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> Date: Mon, 16 Jan 2012 09:03:17 -0500 In-Reply-To: ("Joakim =?UTF-8?Q?H=C3=A5rsman?="'s message of "Sat, 14 Jan 2012 17:40:51 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Note: I know very little about w32. > - 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)); Can we move the test elsewhere by defining (or #defining) our own SetWindowText which uses either of the two? > @@ -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)); > + } > } The two var declarations (WNDCLASSW uwc and WNDCLASS wc) should be moved within their respective branch. And it'd be better if we could share some code between the two branches, e.g. using a macro. Stefan From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Jan 2012 19:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132734614125557 (code B ref 10299); Mon, 23 Jan 2012 19:16:01 +0000 Received: (at 10299) by debbugs.gnu.org; 23 Jan 2012 19:15:41 +0000 Received: from localhost ([127.0.0.1]:41023 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RpPMi-0006e9-CH for submit@debbugs.gnu.org; Mon, 23 Jan 2012 14:15:41 -0500 Received: from mail-bk0-f44.google.com ([209.85.214.44]:57045) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RpPMf-0006cM-Ni for 10299@debbugs.gnu.org; Mon, 23 Jan 2012 14:15:39 -0500 Received: by bkbzt4 with SMTP id zt4so809540bkb.3 for <10299@debbugs.gnu.org>; Mon, 23 Jan 2012 11:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7TREjgiqpaf+48W/ToFURz6jJOMX+hKgOC9u5JyqKaw=; b=dxS3mMSzC1bvM+BJ7/gh1y2w3ten10YzYbUR0vjtUpqKXAF7a8Icnj6Z0UQ9xDSKfR NThuR4sYZVx3j/41Vbd1VhU3F8hAr4jhoIP59q6zCadPEm95XLA+/WnONeghOsG0VXs3 DGE9RjCuZF0s855z0TB+CID4YnFV561GZxNdQ= MIME-Version: 1.0 Received: by 10.205.128.140 with SMTP id he12mr3854118bkc.76.1327346115674; Mon, 23 Jan 2012 11:15:15 -0800 (PST) Received: by 10.205.128.17 with HTTP; Mon, 23 Jan 2012 11:15:15 -0800 (PST) In-Reply-To: References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> Date: Mon, 23 Jan 2012 20:15:15 +0100 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) I've amended the patch to take your comments into account. Note that SetWindowText is already a macro that expands to SetWindowTextA or SetWindowTextW depending on whether UNICODE is defined. However, to retain compatibility with Windows 95, Emacs doesn't define UNICODE and instead uses Unicode APIs directly where it needs them. Still, the duplicated code was annoying, so I defined a simple wrapper function which also gives a good place to document why the code looks the way it does. I also put the initialization of the window class structure into a macro in w32.h, I wasn't entirely sure where to put it. Here's the current version of the patch: =3D=3D=3D modified file 'src/w32.h' --- src/w32.h 2011-10-28 09:54:02 +0000 +++ src/w32.h 2012-01-23 19:10:04 +0000 @@ -159,5 +159,18 @@ const void* buf, size_t sz); #endif /* HAVE_GNUTLS */ +#define INIT_WINDOW_CLASS(wc) \ + wc.style =3D CS_HREDRAW | CS_VREDRAW; \ + wc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; \ + wc.cbClsExtra =3D 0; \ + wc.cbWndExtra =3D WND_EXTRA_BYTES; \ + wc.hInstance =3D hinst; \ + wc.hIcon =3D LoadIcon (hinst, EMACS_CLASS); \ + wc.hCursor =3D w32_load_cursor (IDC_ARROW); \ + wc.hbrBackground =3D NULL; \ + wc.lpszMenuName =3D NULL; \ + + + #endif /* EMACS_W32_H */ =3D=3D=3D modified file 'src/w32fns.c' --- src/w32fns.c 2011-12-04 08:02:42 +0000 +++ src/w32fns.c 2012-01-23 19:10:04 +0000 @@ -1641,6 +1641,20 @@ } +/* 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. */ + +void +w32_set_frame_text(HWND hwnd, LPCSTR text) +{ + if (os_subtype =3D=3D OS_NT) + SetWindowTextW (hwnd, (LPCWSTR)text); + else + SetWindowTextA (hwnd, text); +} /* Change the name of frame F to NAME. If NAME is nil, set F's name to w32_id_name. @@ -1697,10 +1711,10 @@ if (FRAME_W32_WINDOW (f)) { if (STRING_MULTIBYTE (name)) - name =3D ENCODE_SYSTEM (name); - + name =3D ENCODE_SYSTEM (name); + BLOCK_INPUT; - SetWindowText (FRAME_W32_WINDOW (f), SDATA (name)); + w32_set_frame_text(FRAME_W32_WINDOW (f), SDATA (name)); UNBLOCK_INPUT; } } @@ -1746,7 +1760,7 @@ name =3D ENCODE_SYSTEM (name); BLOCK_INPUT; - SetWindowText (FRAME_W32_WINDOW (f), SDATA (name)); + w32_set_frame_text(FRAME_W32_WINDOW (f), SDATA (name)); UNBLOCK_INPUT; } } @@ -1785,20 +1799,23 @@ static BOOL w32_init_class (HINSTANCE hinst) { - WNDCLASS wc; - - wc.style =3D CS_HREDRAW | CS_VREDRAW; - wc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; - wc.cbClsExtra =3D 0; - wc.cbWndExtra =3D WND_EXTRA_BYTES; - wc.hInstance =3D hinst; - wc.hIcon =3D LoadIcon (hinst, EMACS_CLASS); - wc.hCursor =3D w32_load_cursor (IDC_ARROW); - wc.hbrBackground =3D NULL; /* GetStockObject (WHITE_BRUSH); */ - wc.lpszMenuName =3D NULL; - wc.lpszClassName =3D EMACS_CLASS; - - return (RegisterClass (&wc)); + + if (os_subtype =3D=3D OS_NT) + { + WNDCLASSW uwc; + INIT_WINDOW_CLASS(uwc); + uwc.lpszClassName =3D L"Emacs"; + + return (RegisterClassW (&uwc)); + } + else + { + WNDCLASS wc; + INIT_WINDOW_CLASS(wc); + wc.lpszClassName =3D EMACS_CLASS; + + return (RegisterClass (&wc)); + } } static HWND @@ -2248,8 +2265,16 @@ msh_mousewheel =3D RegisterWindowMessage (MSH_MOUSEWHEEL); - while (GetMessage (&msg, NULL, 0, 0)) + while (1) { + if (os_subtype =3D=3D OS_NT) + result =3D GetMessageW (&msg, NULL, 0, 0); + else + result =3D GetMessage (&msg, NULL, 0, 0); + + if (!result) + break; + if (msg.hwnd =3D=3D NULL) { switch (msg.message) @@ -2915,8 +2940,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 =3D wParam & 0x0000FFFF; + unsigned short hi =3D (wParam & 0xFFFF0000) >> 8; + wParam =3D hi | lo; + + W32Msg wmsg; + wmsg.dwModifiers =3D 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 16 January 2012 15:03, Stefan Monnier wrote: > Note: I know very little about w32. > >> - =A0 =A0 =A0SetWindowText (FRAME_W32_WINDOW (f), SDATA (name)); >> + =A0 =A0 =A0if (os_subtype =3D=3D OS_NT) >> + =A0 =A0 =A0 =A0SetWindowTextW (FRAME_W32_WINDOW (f), SDATA (name)); >> + =A0 =A0 =A0else >> + =A0 =A0 =A0 =A0SetWindowText (FRAME_W32_WINDOW (f), SDATA (name)); > > Can we move the test elsewhere by defining (or #defining) our own > SetWindowText which uses either of the two? > >> @@ -1785,20 +1791,39 @@ >> =A0static BOOL >> =A0w32_init_class (HINSTANCE hinst) >> =A0{ >> - =A0WNDCLASS wc; >> - >> - =A0wc.style =3D CS_HREDRAW | CS_VREDRAW; >> - =A0wc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; >> - =A0wc.cbClsExtra =3D 0; >> - =A0wc.cbWndExtra =3D WND_EXTRA_BYTES; >> - =A0wc.hInstance =3D hinst; >> - =A0wc.hIcon =3D LoadIcon (hinst, EMACS_CLASS); >> - =A0wc.hCursor =3D w32_load_cursor (IDC_ARROW); >> - =A0wc.hbrBackground =3D NULL; /* GetStockObject (WHITE_BRUSH); =A0*/ >> - =A0wc.lpszMenuName =3D NULL; >> - =A0wc.lpszClassName =3D EMACS_CLASS; >> - >> - =A0return (RegisterClass (&wc)); >> + =A0WNDCLASSW uwc; >> + =A0WNDCLASS =A0wc; >> + >> + =A0if (os_subtype =3D=3D OS_NT) >> + =A0 =A0{ >> + =A0 =A0 =A0uwc.style =3D CS_HREDRAW | CS_VREDRAW; >> + =A0 =A0 =A0uwc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; >> + =A0 =A0 =A0uwc.cbClsExtra =3D 0; >> + =A0 =A0 =A0uwc.cbWndExtra =3D WND_EXTRA_BYTES; >> + =A0 =A0 =A0uwc.hInstance =3D hinst; >> + =A0 =A0 =A0uwc.hIcon =3D LoadIcon (hinst, EMACS_CLASS); >> + =A0 =A0 =A0uwc.hCursor =3D w32_load_cursor (IDC_ARROW); >> + =A0 =A0 =A0uwc.hbrBackground =3D NULL; /* GetStockObject (WHITE_BRUSH)= ; =A0*/ >> + =A0 =A0 =A0uwc.lpszMenuName =3D NULL; >> + =A0 =A0 =A0uwc.lpszClassName =3D L"Emacs"; >> + >> + =A0 =A0 =A0return (RegisterClassW (&uwc)); >> + =A0 =A0} >> + =A0else >> + =A0 =A0{ >> + =A0 =A0 =A0wc.style =3D CS_HREDRAW | CS_VREDRAW; >> + =A0 =A0 =A0wc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; >> + =A0 =A0 =A0wc.cbClsExtra =3D 0; >> + =A0 =A0 =A0wc.cbWndExtra =3D WND_EXTRA_BYTES; >> + =A0 =A0 =A0wc.hInstance =3D hinst; >> + =A0 =A0 =A0wc.hIcon =3D LoadIcon (hinst, EMACS_CLASS); >> + =A0 =A0 =A0wc.hCursor =3D w32_load_cursor (IDC_ARROW); >> + =A0 =A0 =A0wc.hbrBackground =3D NULL; /* GetStockObject (WHITE_BRUSH);= =A0*/ >> + =A0 =A0 =A0wc.lpszMenuName =3D NULL; >> + =A0 =A0 =A0wc.lpszClassName =3D EMACS_CLASS; >> + >> + =A0 =A0 =A0return (RegisterClass (&wc)); >> + =A0 =A0} >> =A0} > > The two var declarations (WNDCLASSW uwc and WNDCLASS wc) should be moved > within their respective branch. =A0And it'd be better if we could share > some code between the two branches, e.g. using a macro. > > > =A0 =A0 =A0 =A0Stefan From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Jan 2012 01:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: Eli Zaretskii , 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132736894429478 (code B ref 10299); Tue, 24 Jan 2012 01:36:02 +0000 Received: (at 10299) by debbugs.gnu.org; 24 Jan 2012 01:35:44 +0000 Received: from localhost ([127.0.0.1]:41139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RpVIV-0007fP-Ql for submit@debbugs.gnu.org; Mon, 23 Jan 2012 20:35:44 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.183]:47823) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RpVIT-0007fC-Om for 10299@debbugs.gnu.org; Mon, 23 Jan 2012 20:35:42 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIIJHk9MCos2/2dsb2JhbABCq32CLIEGgXIBAQQBViMFCwstBxIUGA0QAROID7heiH6DKASIO5pzhFc X-IronPort-AV: E=Sophos;i="4.71,559,1320642000"; d="scan'208";a="158385321" Received: from 76-10-139-54.dsl.teksavvy.com (HELO ceviche.home) ([76.10.139.54]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 23 Jan 2012 20:35:18 -0500 Received: by ceviche.home (Postfix, from userid 20848) id F3217660FE; Mon, 23 Jan 2012 20:35:17 -0500 (EST) From: Stefan Monnier Message-ID: References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> Date: Mon, 23 Jan 2012 20:35:17 -0500 In-Reply-To: ("Joakim =?UTF-8?Q?H=C3=A5rsman?="'s message of "Mon, 23 Jan 2012 20:15:15 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > I've amended the patch to take your comments into account. Thank you. > --- src/w32.h 2011-10-28 09:54:02 +0000 > +++ src/w32.h 2012-01-23 19:10:04 +0000 > @@ -159,5 +159,18 @@ > const void* buf, size_t sz); > #endif /* HAVE_GNUTLS */ > +#define INIT_WINDOW_CLASS(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; \ > + wc.lpszMenuName = NULL; \ > + > + > + > #endif /* EMACS_W32_H */ Please don't put this macro there: it's not something that's exported to other files, so it is better to keep it close to where it's used. > +/* 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. */ > + > +void > +w32_set_frame_text(HWND hwnd, LPCSTR text) This should be `static', I think, and with a space before the open-paren. > + if (os_subtype == OS_NT) > + result = GetMessageW (&msg, NULL, 0, 0); > + else > + result = GetMessage (&msg, NULL, 0, 0); I'd write it as follows: result = (os_subtype == OS_NT ? GetMessageW : GetMessage) (&msg, NULL, 0, 0); other than that, the code looks fine for me (I'll let Windows users assess whether it actually does what it's meant to do ;-), Stefan From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Andreas Schwab Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Jan 2012 09:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 10299@debbugs.gnu.org, Joakim =?UTF-8?Q?H=C3=A5rsman?= Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.13273980787268 (code B ref 10299); Tue, 24 Jan 2012 09:42:02 +0000 Received: (at 10299) by debbugs.gnu.org; 24 Jan 2012 09:41:18 +0000 Received: from localhost ([127.0.0.1]:41360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RpcsP-0001tB-Ff for submit@debbugs.gnu.org; Tue, 24 Jan 2012 04:41:18 -0500 Received: from mail-out.m-online.net ([212.18.0.10]:34510) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RpcsN-0001t3-0l for 10299@debbugs.gnu.org; Tue, 24 Jan 2012 04:41:16 -0500 Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id D10241800141; Tue, 24 Jan 2012 10:40:53 +0100 (CET) X-Auth-Info: yHQS2FxWXgAVop9dgEmKp1S5JBGJ2Wshh0CAV/ljRPw= Received: from igel.home (ppp-93-104-151-85.dynamic.mnet-online.de [93.104.151.85]) by mail.mnet-online.de (Postfix) with ESMTPA id 0CB1A1C00045; Tue, 24 Jan 2012 10:40:54 +0100 (CET) Received: by igel.home (Postfix, from userid 501) id 78211CA299; Tue, 24 Jan 2012 10:40:53 +0100 (CET) From: Andreas Schwab References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> X-Yow: I am NOT a nut.... Date: Tue, 24 Jan 2012 10:40:52 +0100 In-Reply-To: (Stefan Monnier's message of "Mon, 23 Jan 2012 20:35:17 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Stefan Monnier writes: >> + if (os_subtype == OS_NT) >> + result = GetMessageW (&msg, NULL, 0, 0); >> + else >> + result = GetMessage (&msg, NULL, 0, 0); > > I'd write it as follows: > > result = (os_subtype == OS_NT ? GetMessageW : GetMessage) (&msg, NULL, 0, 0); That can fail if either of the functions is defined only as a function-like macro. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Juanma Barranquero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Jan 2012 12:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andreas Schwab Cc: Stefan Monnier , Joakim =?UTF-8?Q?H=C3=A5rsman?= , 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132740670019941 (code B ref 10299); Tue, 24 Jan 2012 12:05:01 +0000 Received: (at 10299) by debbugs.gnu.org; 24 Jan 2012 12:05:00 +0000 Received: from localhost ([127.0.0.1]:41397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rpf7Q-0005BW-RS for submit@debbugs.gnu.org; Tue, 24 Jan 2012 07:04:58 -0500 Received: from mail-pw0-f44.google.com ([209.85.160.44]:40879) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rpf7N-0005BG-6k for 10299@debbugs.gnu.org; Tue, 24 Jan 2012 07:04:54 -0500 Received: by pbbb11 with SMTP id b11so719482pbb.3 for <10299@debbugs.gnu.org>; Tue, 24 Jan 2012 04:04:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=0V0ENGfh1k308EzQJC6+CA4cSYnjmCbrD0tpMK80Ds4=; b=Tp6t19rhTOQ7Lg7W5zs5x7yildS1dJU9Pb+6II2dvEu6NFk5nXqUmzObiMHiXNsP1U at663vqUMtEkfHoAxgVoro/JVq1JkE/BJqGKHpvMeA8w0jiZirfXyr4cC9bfHflI7EkZ amIKXaU6WKtVDNnerq8Dy+sSHXcU2SlumlPfs= Received: by 10.68.74.134 with SMTP id t6mr30678156pbv.26.1327406667258; Tue, 24 Jan 2012 04:04:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.143.37.9 with HTTP; Tue, 24 Jan 2012 04:03:46 -0800 (PST) In-Reply-To: References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> From: Juanma Barranquero Date: Tue, 24 Jan 2012 13:03:46 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Tue, Jan 24, 2012 at 10:40, Andreas Schwab wrote= : >> =C2=A0 result =3D (os_subtype =3D=3D OS_NT ? GetMessageW : GetMessage) (= &msg, NULL, 0, 0); > > That can fail if either of the functions is defined only as a > function-like macro. OTOH, if the patch explicitly references W functions, it should be using RegisterClassA and GetMessageA for the explicit A versions. =C2=A0 =C2=A0 Juanma From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Jan 2012 20:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juanma Barranquero Cc: Andreas Schwab , Stefan Monnier , 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132743779910647 (code B ref 10299); Tue, 24 Jan 2012 20:44:01 +0000 Received: (at 10299) by debbugs.gnu.org; 24 Jan 2012 20:43:19 +0000 Received: from localhost ([127.0.0.1]:42132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RpnD4-0002le-AT for submit@debbugs.gnu.org; Tue, 24 Jan 2012 15:43:18 -0500 Received: from mail-bk0-f44.google.com ([209.85.214.44]:55108) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RpnD0-0002lR-Sp for 10299@debbugs.gnu.org; Tue, 24 Jan 2012 15:43:16 -0500 Received: by bkbzt4 with SMTP id zt4so1807414bkb.3 for <10299@debbugs.gnu.org>; Tue, 24 Jan 2012 12:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3vvwvcAzhJGG+0pM0S6fw1hJO1fIVy+a72sMEHi2je8=; b=Fn+R0qXUyUWDlt4B88oQVDqpBhhUyLDPbrucgSjVykdsk+I7UzC5IGt85kt0+MeCoD 2Ps7a7uW0QxXV51CDT/JsFmUzjhSZlz1yX01zCE9ILquNlC7fyEAgaCmkwdN/jukYsFl erCTMZbMfDJzDoB4xItQL8Eo15tdzUJm/trBo= MIME-Version: 1.0 Received: by 10.205.131.13 with SMTP id ho13mr4087913bkc.58.1327437766937; Tue, 24 Jan 2012 12:42:46 -0800 (PST) Received: by 10.205.128.17 with HTTP; Tue, 24 Jan 2012 12:42:46 -0800 (PST) In-Reply-To: References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> Date: Tue, 24 Jan 2012 21:42:46 +0100 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) GetMessage is a macro, many Windows API functions are, and switches between GetMessageA and GetMessageW based on whether UNICODE is defined. I really should explicitly use GetMessageA, I just missed it. I switched to Stefan's suggestion, but with explicit use of GetMessageA. Note that this makes that line longer than 80 chars. Here's an amended patch that also moves the definition of the INIT_WINDOW_CLASS macro to just before use, and makes w32_set_frame_text static. =3D=3D=3D modified file 'src/w32fns.c' --- src/w32fns.c 2011-12-04 08:02:42 +0000 +++ src/w32fns.c 2012-01-24 20:22:52 +0000 @@ -1641,6 +1641,20 @@ } +/* 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 =3D=3D OS_NT) + SetWindowTextW (hwnd, (LPCWSTR)text); + else + SetWindowTextA (hwnd, text); +} /* Change the name of frame F to NAME. If NAME is nil, set F's name to w32_id_name. @@ -1697,10 +1711,10 @@ if (FRAME_W32_WINDOW (f)) { if (STRING_MULTIBYTE (name)) - name =3D ENCODE_SYSTEM (name); - + name =3D ENCODE_SYSTEM (name); + BLOCK_INPUT; - SetWindowText (FRAME_W32_WINDOW (f), SDATA (name)); + w32_set_frame_text(FRAME_W32_WINDOW (f), SDATA (name)); UNBLOCK_INPUT; } } @@ -1746,7 +1760,7 @@ name =3D ENCODE_SYSTEM (name); BLOCK_INPUT; - SetWindowText (FRAME_W32_WINDOW (f), SDATA (name)); + w32_set_frame_text(FRAME_W32_WINDOW (f), SDATA (name)); UNBLOCK_INPUT; } } @@ -1782,23 +1796,37 @@ static LRESULT CALLBACK w32_wnd_proc (HWND, UINT, WPARAM, LPARAM); +#define INIT_WINDOW_CLASS(wc) \ + wc.style =3D CS_HREDRAW | CS_VREDRAW; \ + wc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; \ + wc.cbClsExtra =3D 0; \ + wc.cbWndExtra =3D WND_EXTRA_BYTES; \ + wc.hInstance =3D hinst; \ + wc.hIcon =3D LoadIcon (hinst, EMACS_CLASS); \ + wc.hCursor =3D w32_load_cursor (IDC_ARROW); \ + wc.hbrBackground =3D NULL; \ + wc.lpszMenuName =3D NULL; \ + static BOOL w32_init_class (HINSTANCE hinst) { - WNDCLASS wc; - - wc.style =3D CS_HREDRAW | CS_VREDRAW; - wc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; - wc.cbClsExtra =3D 0; - wc.cbWndExtra =3D WND_EXTRA_BYTES; - wc.hInstance =3D hinst; - wc.hIcon =3D LoadIcon (hinst, EMACS_CLASS); - wc.hCursor =3D w32_load_cursor (IDC_ARROW); - wc.hbrBackground =3D NULL; /* GetStockObject (WHITE_BRUSH); */ - wc.lpszMenuName =3D NULL; - wc.lpszClassName =3D EMACS_CLASS; - - return (RegisterClass (&wc)); + + if (os_subtype =3D=3D OS_NT) + { + WNDCLASSW uwc; + INIT_WINDOW_CLASS(uwc); + uwc.lpszClassName =3D L"Emacs"; + + return (RegisterClassW (&uwc)); + } + else + { + WNDCLASS wc; + INIT_WINDOW_CLASS(wc); + wc.lpszClassName =3D EMACS_CLASS; + + return (RegisterClassA (&wc)); + } } static HWND @@ -2248,8 +2276,13 @@ msh_mousewheel =3D RegisterWindowMessage (MSH_MOUSEWHEEL); - while (GetMessage (&msg, NULL, 0, 0)) + while (1) { + result =3D (os_subtype =3D=3D OS_NT ? GetMessageW : GetMessageA) (&msg, NULL, 0, 0); + + if (!result) + break; + if (msg.hwnd =3D=3D 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 =3D wParam & 0x0000FFFF; + unsigned short hi =3D (wParam & 0xFFFF0000) >> 8; + wParam =3D hi | lo; + + W32Msg wmsg; + wmsg.dwModifiers =3D 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 24 January 2012 13:03, Juanma Barranquero wrote: > On Tue, Jan 24, 2012 at 10:40, Andreas Schwab wro= te: > >>> =A0 result =3D (os_subtype =3D=3D OS_NT ? GetMessageW : GetMessage) (&m= sg, NULL, 0, 0); >> >> That can fail if either of the functions is defined only as a >> function-like macro. > > OTOH, if the patch explicitly references W functions, it should be > using RegisterClassA and GetMessageA for the explicit A versions. > > =A0 =A0 Juanma From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Jul 2012 14:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: lekktu@gmail.com, 10299@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.134348746719481 (code B ref 10299); Sat, 28 Jul 2012 14:58:02 +0000 Received: (at 10299) by debbugs.gnu.org; 28 Jul 2012 14:57:47 +0000 Received: from localhost ([127.0.0.1]:46663 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sv8Sg-00054A-Uq for submit@debbugs.gnu.org; Sat, 28 Jul 2012 10:57:47 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:36757) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sv8Sc-00053z-O8 for 10299@debbugs.gnu.org; Sat, 28 Jul 2012 10:57:44 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M7V00300L2ST800@a-mtaout22.012.net.il> for 10299@debbugs.gnu.org; Sat, 28 Jul 2012 17:49:57 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M7V003W2L79P420@a-mtaout22.012.net.il>; Sat, 28 Jul 2012 17:49:57 +0300 (IDT) Date: Sat, 28 Jul 2012 17:50:06 +0300 From: Eli Zaretskii In-reply-to: Message-id: <836298hrdt.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Tue, 24 Jan 2012 21:42:46 +0100 > From: Joakim H=E5rsman > Cc: Andreas Schwab , 10299@debbugs.gnu.org >=20 > GetMessage is a macro, many Windows API functions are, and switches > between GetMessageA and GetMessageW based on whether UNICODE is > defined. I really should explicitly use GetMessageA, I just missed = it. >=20 > I switched to Stefan's suggestion, but with explicit use of > GetMessageA. Note that this makes that line longer than 80 chars. >=20 > Here's an amended patch that also moves the definition of the > INIT_WINDOW_CLASS macro to just before use, and makes > w32_set_frame_text static. Thanks. It's been a while since you submitted this, so sorry for the delay. We are now past Emacs 24.1 release, so we are free to install your changes. However, when I applied the patch, I bumped into several problems. First, I don't understand why we need this part: +/* 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 =3D=3D OS_NT) + SetWindowTextW (hwnd, (LPCWSTR)text); + else + SetWindowTextA (hwnd, text); +} /* Change the name of frame F to NAME. If NAME is nil, set F's na= me to =09 w32_id_name. @@ -1697,10 +1711,10 @@ if (FRAME_W32_WINDOW (f)) { =09 if (STRING_MULTIBYTE (name)) - name =3D ENCODE_SYSTEM (name); - + name =3D ENCODE_SYSTEM (name); + =09 BLOCK_INPUT; - SetWindowText (FRAME_W32_WINDOW (f), SDATA (name)); + w32_set_frame_text(FRAME_W32_WINDOW (f), SDATA (name)); =09 UNBLOCK_INPUT; } } @@ -1746,7 +1760,7 @@ =09 name =3D ENCODE_SYSTEM (name); =09 BLOCK_INPUT; - SetWindowText (FRAME_W32_WINDOW (f), SDATA (name)); + w32_set_frame_text(FRAME_W32_WINDOW (f), SDATA (name)); =09 UNBLOCK_INPUT; } } Why do we need to use SetWindowTextW, when all we change is the way w= e request messages for Emacs? With the patch below, which doesn't use this part, I see no problems at all with the titles of Emacs frames. Can you tell me how to reproduce the problem with the title? Moreover, passing 'SDATA (name)' to SetWindowTextW is wrong, since that function expects a wchar_t *, not a char *, as pointer to the text to display in the title. (The compiler should warn about that, didn't it?) So if we do need this part, we will need to convert the frame name into a wide character string. Next, this part, whose need was not entirely understood even when you submitted the patches: @@ -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 =3D wParam & 0x0000FFFF; + unsigned short hi =3D (wParam & 0xFFFF0000) >> 8; + wParam =3D hi | lo; + + W32Msg wmsg; + wmsg.dwModifiers =3D w32_get_key_modifiers (wParam, lPar= am); + 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, lPa= ram)); =09 break; This doesn't work in a locale where Unicode codepoints of the characters generated by the localized keyboard are above 255. (I liv= e in one such locale.) In those locales, this snippet produces the wrong characters. The root cause of this is that WM_CHAR's wParam is not really the Unicode codepoint of the character I type, it's some garbled value. After looking into this, my conclusion was that your patches didn't do everything that's needed to get true Unicode character input. This page: http://social.msdn.microsoft.com/forums/en-US/windowssdk/thread/07a= fec87-68c1-4a56-bf46-a38a9c2232e9/ suggests what needs to be done. So I went ahead and made the few additional changes mentioned there, and the Unicode input started working for me. With these additional changes, the funky bit-tweakin= g code is no longer needed, at least for the characters in the 0x05nn range of Unicode that I tried. I hope it will work with your custom keyboard as well. The patches I tried are below. I'd appreciate if you could try them and see if they work with your custom keyboard layouts. If they do, = I will install them. (Juanma, I'd appreciate if you could try this as well.) Thanks. =3D=3D=3D modified file 'src/w32fns.c' --- src/w32fns.c=092012-07-27 09:24:34 +0000 +++ src/w32fns.c=092012-07-28 14:28:29 +0000 @@ -1780,23 +1780,37 @@ w32_load_cursor (LPCTSTR name) =20 static LRESULT CALLBACK w32_wnd_proc (HWND, UINT, WPARAM, LPARAM); =20 +#define INIT_WINDOW_CLASS(WC)=09=09=09 \ + (WC).style =3D CS_HREDRAW | CS_VREDRAW;=09=09 \ + (WC).lpfnWndProc =3D (WNDPROC) w32_wnd_proc; \ + (WC).cbClsExtra =3D 0; \ + (WC).cbWndExtra =3D WND_EXTRA_BYTES; \ + (WC).hInstance =3D hinst; \ + (WC).hIcon =3D LoadIcon (hinst, EMACS_CLASS); \ + (WC).hCursor =3D w32_load_cursor (IDC_ARROW); \ + (WC).hbrBackground =3D NULL; \ + (WC).lpszMenuName =3D NULL; \ + static BOOL w32_init_class (HINSTANCE hinst) { - WNDCLASS wc; =20 - wc.style =3D CS_HREDRAW | CS_VREDRAW; - wc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; - wc.cbClsExtra =3D 0; - wc.cbWndExtra =3D WND_EXTRA_BYTES; - wc.hInstance =3D hinst; - wc.hIcon =3D LoadIcon (hinst, EMACS_CLASS); - wc.hCursor =3D w32_load_cursor (IDC_ARROW); - wc.hbrBackground =3D NULL; /* GetStockObject (WHITE_BRUSH); */ - wc.lpszMenuName =3D NULL; - wc.lpszClassName =3D EMACS_CLASS; + if (os_subtype =3D=3D OS_NT) + { + WNDCLASSW uwc; + INIT_WINDOW_CLASS(uwc); + uwc.lpszClassName =3D L"Emacs"; + + return RegisterClassW (&uwc); + } + else + { + WNDCLASS wc; + INIT_WINDOW_CLASS(wc); + wc.lpszClassName =3D EMACS_CLASS; =20 - return (RegisterClass (&wc)); + return RegisterClassA (&wc); + } } =20 static HWND @@ -2246,7 +2260,7 @@ w32_msg_pump (deferred_msg * msg_buf) =20 msh_mousewheel =3D RegisterWindowMessage (MSH_MOUSEWHEEL); =20 - while (GetMessage (&msg, NULL, 0, 0)) + while ((os_subtype =3D=3D OS_NT ? GetMessageW : GetMessageA) (&msg= , NULL, 0, 0)) { if (msg.hwnd =3D=3D NULL) =09{ @@ -2341,7 +2355,10 @@ w32_msg_pump (deferred_msg * msg_buf) =09} else =09{ -=09 DispatchMessage (&msg); +=09 if (os_subtype =3D=3D OS_NT) +=09 DispatchMessageW (&msg); +=09 else +=09 DispatchMessageA (&msg); =09} =20 /* Exit nested loop when our deferred message has completed. = */ @@ -2918,8 +2935,18 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARA =20 case WM_SYSCHAR: case WM_CHAR: - post_character_message (hwnd, msg, wParam, lParam, -=09=09=09 w32_get_key_modifiers (wParam, lParam)); + if (wParam > 255 ) + { + W32Msg wmsg; + + wmsg.dwModifiers =3D 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, lPara= m)); break; =20 case WM_UNICHAR: @@ -3801,7 +3828,7 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARA =09} =20 dflt: - return DefWindowProc (hwnd, msg, wParam, lParam); + return (os_subtype =3D=3D OS_NT ? DefWindowProcW : DefWindowP= rocA) (hwnd, msg, wParam, lParam); } =20 /* The most common default return code for handled messages is 0. = */ From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Aug 2012 20:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: lekktu@gmail.com, 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.134428488229211 (code B ref 10299); Mon, 06 Aug 2012 20:29:01 +0000 Received: (at 10299) by debbugs.gnu.org; 6 Aug 2012 20:28:02 +0000 Received: from localhost ([127.0.0.1]:38085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyTuD-0007ao-1C for submit@debbugs.gnu.org; Mon, 06 Aug 2012 16:28:02 -0400 Received: from mail-gg0-f172.google.com ([209.85.161.172]:48378) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyTu9-0007ae-7U for 10299@debbugs.gnu.org; Mon, 06 Aug 2012 16:27:59 -0400 Received: by ggnc4 with SMTP id c4so3058207ggn.3 for <10299@debbugs.gnu.org>; Mon, 06 Aug 2012 13:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lHJptTfRIxtW4khXSenQJ8hMuFeSU8+qJu6X+DqnJiE=; b=CF+7aqU3IDPQ4nvCvG3+tVvbheAYiSMCCuc6NB6LcOG9ZokmIg1TYMIPatiGkIQraD LwDstcdXbdIpDWxSThCcYb4gS7pCVJegmzNBLD9Fg2qCHPkO41iUYwG+pcQMeOKCj7C4 QVdv3p0tZT5XRnSZyvgVhtDTETYHJ2toR6/xCOeQ3RqyBY+6DEORoNfQ+GVOTqBZfw1Y MMl3lS+9OQ9r/LePAh5yas4q8YLQTt7Nxuydzv7S96YCzYG/IbhN/WGrxbgCn3fg2HWV XW1Eo9cTDA5/aJM3hA9Y5ZqzK01YYola8AeIKgEtZeIuqLcgejWN0rC/iMYDVXdA04pq BeBg== MIME-Version: 1.0 Received: by 10.50.6.229 with SMTP id e5mr6633193iga.9.1344284401527; Mon, 06 Aug 2012 13:20:01 -0700 (PDT) Received: by 10.50.45.70 with HTTP; Mon, 6 Aug 2012 13:20:01 -0700 (PDT) In-Reply-To: <836298hrdt.fsf@gnu.org> References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> <836298hrdt.fsf@gnu.org> Date: Mon, 6 Aug 2012 22:20:01 +0200 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Sorry for the late reply, I've been away on vacation. 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 I change w32_set frame text to always call SetWindowText I get a default frame title of "e". Changing DispatchMessage to use the wide version when appropriate doesn't help either. I'm not surprised the WM_CHAR bit twiddling was wrong since the actual format was so badly documented, your version looks much better. I'll try your new patch tomorrow and get back with details on how it worked= , On 28 July 2012 16:50, Eli Zaretskii wrote: >> Date: Tue, 24 Jan 2012 21:42:46 +0100 >> From: Joakim H=E5rsman >> Cc: Andreas Schwab , 10299@debbugs.gnu.org >> >> GetMessage is a macro, many Windows API functions are, and switches >> between GetMessageA and GetMessageW based on whether UNICODE is >> defined. I really should explicitly use GetMessageA, I just missed it. >> >> I switched to Stefan's suggestion, but with explicit use of >> GetMessageA. Note that this makes that line longer than 80 chars. >> >> Here's an amended patch that also moves the definition of the >> INIT_WINDOW_CLASS macro to just before use, and makes >> w32_set_frame_text static. > > Thanks. It's been a while since you submitted this, so sorry for the > delay. We are now past Emacs 24.1 release, so we are free to install > your changes. > > However, when I applied the patch, I bumped into several problems. > First, I don't understand why we need this part: > > +/* 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 =3D=3D OS_NT) > + SetWindowTextW (hwnd, (LPCWSTR)text); > + else > + SetWindowTextA (hwnd, text); > +} > > /* Change the name of frame F to NAME. If NAME is nil, set F's name t= o > w32_id_name. > @@ -1697,10 +1711,10 @@ > if (FRAME_W32_WINDOW (f)) > { > if (STRING_MULTIBYTE (name)) > - name =3D ENCODE_SYSTEM (name); > - > + name =3D ENCODE_SYSTEM (name); > + > BLOCK_INPUT; > - SetWindowText (FRAME_W32_WINDOW (f), SDATA (name)); > + w32_set_frame_text(FRAME_W32_WINDOW (f), SDATA (name)); > UNBLOCK_INPUT; > } > } > @@ -1746,7 +1760,7 @@ > name =3D ENCODE_SYSTEM (name); > > BLOCK_INPUT; > - SetWindowText (FRAME_W32_WINDOW (f), SDATA (name)); > + w32_set_frame_text(FRAME_W32_WINDOW (f), SDATA (name)); > UNBLOCK_INPUT; > } > } > > Why do we need to use SetWindowTextW, when all we change is the way we > request messages for Emacs? With the patch below, which doesn't use > this part, I see no problems at all with the titles of Emacs frames. > Can you tell me how to reproduce the problem with the title? > > Moreover, passing 'SDATA (name)' to SetWindowTextW is wrong, since > that function expects a wchar_t *, not a char *, as pointer to the > text to display in the title. (The compiler should warn about that, > didn't it?) So if we do need this part, we will need to convert the > frame name into a wide character string. > > Next, this part, whose need was not entirely understood even when you > submitted the patches: > > @@ -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 =3D wParam & 0x0000FFFF; > + unsigned short hi =3D (wParam & 0xFFFF0000) >> 8; > + wParam =3D hi | lo; > + > + W32Msg wmsg; > + wmsg.dwModifiers =3D 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; > > This doesn't work in a locale where Unicode codepoints of the > characters generated by the localized keyboard are above 255. (I live > in one such locale.) In those locales, this snippet produces the > wrong characters. The root cause of this is that WM_CHAR's wParam is > not really the Unicode codepoint of the character I type, it's some > garbled value. After looking into this, my conclusion was that your > patches didn't do everything that's needed to get true Unicode > character input. This page: > > http://social.msdn.microsoft.com/forums/en-US/windowssdk/thread/07afec8= 7-68c1-4a56-bf46-a38a9c2232e9/ > > suggests what needs to be done. So I went ahead and made the few > additional changes mentioned there, and the Unicode input started > working for me. With these additional changes, the funky bit-tweaking > code is no longer needed, at least for the characters in the 0x05nn > range of Unicode that I tried. I hope it will work with your custom > keyboard as well. > > The patches I tried are below. I'd appreciate if you could try them > and see if they work with your custom keyboard layouts. If they do, I > will install them. > > (Juanma, I'd appreciate if you could try this as well.) > > Thanks. > > > =3D=3D=3D modified file 'src/w32fns.c' > --- src/w32fns.c 2012-07-27 09:24:34 +0000 > +++ src/w32fns.c 2012-07-28 14:28:29 +0000 > @@ -1780,23 +1780,37 @@ w32_load_cursor (LPCTSTR name) > > static LRESULT CALLBACK w32_wnd_proc (HWND, UINT, WPARAM, LPARAM); > > +#define INIT_WINDOW_CLASS(WC) \ > + (WC).style =3D CS_HREDRAW | CS_VREDRAW; \ > + (WC).lpfnWndProc =3D (WNDPROC) w32_wnd_proc; \ > + (WC).cbClsExtra =3D 0; \ > + (WC).cbWndExtra =3D WND_EXTRA_BYTES; \ > + (WC).hInstance =3D hinst; \ > + (WC).hIcon =3D LoadIcon (hinst, EMACS_CLASS); \ > + (WC).hCursor =3D w32_load_cursor (IDC_ARROW); \ > + (WC).hbrBackground =3D NULL; \ > + (WC).lpszMenuName =3D NULL; \ > + > static BOOL > w32_init_class (HINSTANCE hinst) > { > - WNDCLASS wc; > > - wc.style =3D CS_HREDRAW | CS_VREDRAW; > - wc.lpfnWndProc =3D (WNDPROC) w32_wnd_proc; > - wc.cbClsExtra =3D 0; > - wc.cbWndExtra =3D WND_EXTRA_BYTES; > - wc.hInstance =3D hinst; > - wc.hIcon =3D LoadIcon (hinst, EMACS_CLASS); > - wc.hCursor =3D w32_load_cursor (IDC_ARROW); > - wc.hbrBackground =3D NULL; /* GetStockObject (WHITE_BRUSH); */ > - wc.lpszMenuName =3D NULL; > - wc.lpszClassName =3D EMACS_CLASS; > + if (os_subtype =3D=3D OS_NT) > + { > + WNDCLASSW uwc; > + INIT_WINDOW_CLASS(uwc); > + uwc.lpszClassName =3D L"Emacs"; > + > + return RegisterClassW (&uwc); > + } > + else > + { > + WNDCLASS wc; > + INIT_WINDOW_CLASS(wc); > + wc.lpszClassName =3D EMACS_CLASS; > > - return (RegisterClass (&wc)); > + return RegisterClassA (&wc); > + } > } > > static HWND > @@ -2246,7 +2260,7 @@ w32_msg_pump (deferred_msg * msg_buf) > > msh_mousewheel =3D RegisterWindowMessage (MSH_MOUSEWHEEL); > > - while (GetMessage (&msg, NULL, 0, 0)) > + while ((os_subtype =3D=3D OS_NT ? GetMessageW : GetMessageA) (&msg, NU= LL, 0, 0)) > { > if (msg.hwnd =3D=3D NULL) > { > @@ -2341,7 +2355,10 @@ w32_msg_pump (deferred_msg * msg_buf) > } > else > { > - DispatchMessage (&msg); > + if (os_subtype =3D=3D OS_NT) > + DispatchMessageW (&msg); > + else > + DispatchMessageA (&msg); > } > > /* Exit nested loop when our deferred message has completed. */ > @@ -2918,8 +2935,18 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARA > > case WM_SYSCHAR: > case WM_CHAR: > - post_character_message (hwnd, msg, wParam, lParam, > - w32_get_key_modifiers (wParam, lParam)); > + if (wParam > 255 ) > + { > + W32Msg wmsg; > + > + wmsg.dwModifiers =3D 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: > @@ -3801,7 +3828,7 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARA > } > > dflt: > - return DefWindowProc (hwnd, msg, wParam, lParam); > + return (os_subtype =3D=3D OS_NT ? DefWindowProcW : DefWindowProcA= ) (hwnd, msg, wParam, lParam); > } > > /* The most common default return code for handled messages is 0. */ > From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Aug 2012 03:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: lekktu@gmail.com, 10299@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.134430855931580 (code B ref 10299); Tue, 07 Aug 2012 03:03:02 +0000 Received: (at 10299) by debbugs.gnu.org; 7 Aug 2012 03:02:39 +0000 Received: from localhost ([127.0.0.1]:38421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sya46-0008DJ-V5 for submit@debbugs.gnu.org; Mon, 06 Aug 2012 23:02:39 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:36577) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sya43-0008DA-NE for 10299@debbugs.gnu.org; Mon, 06 Aug 2012 23:02:37 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M8D009006O22700@a-mtaout22.012.net.il> for 10299@debbugs.gnu.org; Tue, 07 Aug 2012 05:53:26 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M8D009406P20120@a-mtaout22.012.net.il>; Tue, 07 Aug 2012 05:53:26 +0300 (IDT) Date: Tue, 07 Aug 2012 05:53:29 +0300 From: Eli Zaretskii In-reply-to: Message-id: <83ehnj9zva.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> <836298hrdt.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Mon, 6 Aug 2012 22:20:01 +0200 > From: Joakim H=E5rsman > Cc: lekktu@gmail.com, 10299@debbugs.gnu.org >=20 > Sorry for the late reply, I've been away on vacation. No sweat. Hope you had a good one. > 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 an= d > the second byte therefore is null). This is exaclty the case they t= alk > about at your link. >=20 > If I change w32_set frame text to always call SetWindowText I get a > default frame title of "e". Changing DispatchMessage to use the wid= e > version when appropriate doesn't help either. I didn't see any problem with the frame title, with the patch I sent. I'm curious to hear if you will still see that problem. > I'll try your new patch tomorrow and get back with details on how i= t worked, Thank you. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Jason Rumney Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Aug 2012 12:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: lekktu@gmail.com, Eli Zaretskii , 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.13443422267877 (code B ref 10299); Tue, 07 Aug 2012 12:24:01 +0000 Received: (at 10299) by debbugs.gnu.org; 7 Aug 2012 12:23:46 +0000 Received: from localhost ([127.0.0.1]:39017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Syip6-00022u-Cp for submit@debbugs.gnu.org; Tue, 07 Aug 2012 08:23:46 -0400 Received: from mail-pb0-f44.google.com ([209.85.160.44]:38732) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Syip4-00022m-AO for 10299@debbugs.gnu.org; Tue, 07 Aug 2012 08:23:43 -0400 Received: by pbbrr4 with SMTP id rr4so5636040pbb.3 for <10299@debbugs.gnu.org>; Tue, 07 Aug 2012 05:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=ZT7TAi1dD85eNJatno78tYYGS+p1W5OPSr/5p6/Aom8=; b=H+pLp6Jj5DzY2S7Vwm2l+qSIKxqFyuFb7pUiX6WbGE5+L7G+St6Lh/d7djnn1bsVzb U3f4cwXkwIYm5+aiN/2gs1Y0pbn8NlnzC3JxJMnEbp+lAnAgVTog7NIiZZ3lilDhkITc +kk/BEqqdJ7IeIEBVLjxphSo1zBwZf7PzA7NRhyf9BYmTN5XqKc5r1WgQVw6UfzFihOS GBdBKZqhJeOGUJ9kuP+B3zBK6NcIHMp8fw/5aQYgAB19OB67cGsL9rLyUJgeGDgLGdI6 QOGci1JdlDnJIVT9bQeYS6sf0NEx1hNmHTzyB03mEjoDmPcMi2g9jCq8vvQA1bR5h9YI iMDQ== Received: by 10.68.129.38 with SMTP id nt6mr27683176pbb.76.1344341741930; Tue, 07 Aug 2012 05:15:41 -0700 (PDT) Received: from home.jasonrumney.net ([180.75.28.25]) by mx.google.com with ESMTPS id oj8sm7664085pbb.54.2012.08.07.05.15.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Aug 2012 05:15:40 -0700 (PDT) Received: by home.jasonrumney.net (Postfix, from userid 1000) id D23981125; Tue, 7 Aug 2012 20:15:30 +0800 (MYT) From: Jason Rumney References: <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> <836298hrdt.fsf@gnu.org> Date: Tue, 07 Aug 2012 20:15:30 +0800 In-Reply-To: ("Joakim =?UTF-8?Q?H=C3=A5rsman?="'s message of "Mon, 6 Aug 2012 22:20:01 +0200") Message-ID: <87txweq4nx.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Joakim H=C3=A5rsman 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 =3D=3D 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 =3D ENCODE_SYSTEM (name); >> - >> + name =3D 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 usi= ng this patch. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Aug 2012 19:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: lekktu@gmail.com, 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.134436934120383 (code B ref 10299); Tue, 07 Aug 2012 19:56:02 +0000 Received: (at 10299) by debbugs.gnu.org; 7 Aug 2012 19:55:41 +0000 Received: from localhost ([127.0.0.1]:40356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SypsS-0005Ii-Pf for submit@debbugs.gnu.org; Tue, 07 Aug 2012 15:55:41 -0400 Received: from mail-gg0-f172.google.com ([209.85.161.172]:43231) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SypsR-0005Ib-Fq for 10299@debbugs.gnu.org; Tue, 07 Aug 2012 15:55:39 -0400 Received: by ggnc4 with SMTP id c4so4236117ggn.3 for <10299@debbugs.gnu.org>; Tue, 07 Aug 2012 12:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Dci2Z4G3beCO1f7PGjKXkuj5VuMvsQ0rOUtmgs34k7Y=; b=Ct3WL4KAz/pS4kCSGKqWIGgtSp0z0hMCvRP349iakELz78LWSDEKOchZEUsvypKVzr rSgk5cPnZmLpx0yvJa8d/aoxJHC/Dp/GN819ddfS1/i0fzYNGNgUFGKQZtXS5RK/4Hk2 g/4CeJjlDx+29zM+2jjRVz1U8ZGL1u5K1xpLS67Q5Hu+GPvdXtPbPnIfzDvX7xDH5m9s x02aEhafxa/hR4EESMmmAx7bu9/lTYda8VXkzZvLDSubgvaj95AWI8FCx1Mcal+6Kesm AL1XF3XQa03czxwcjDDJQzs2Jc2mQajBEjKeKGUe/nqn2myEZ88hzudSSw6SdQQmqFrd k/DQ== MIME-Version: 1.0 Received: by 10.50.159.135 with SMTP id xc7mr9892703igb.9.1344368858412; Tue, 07 Aug 2012 12:47:38 -0700 (PDT) Received: by 10.50.45.70 with HTTP; Tue, 7 Aug 2012 12:47:38 -0700 (PDT) In-Reply-To: <83ehnj9zva.fsf@gnu.org> References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> <836298hrdt.fsf@gnu.org> <83ehnj9zva.fsf@gnu.org> Date: Tue, 7 Aug 2012 21:47:38 +0200 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Your patch works fine for me on Windows XP. Unicode input outside the system code page works fine and so does non-ASCII input that is present in the current code page. Since this seems much cleaner than the previous patch, it is definitely the way to go. I think the critical change was switching to both DefWindowProcW and DispatchMessageW (at least that's what http://social.msdn.microsoft.com/forums/en-US/windowssdk/thread/07afec87-68= c1-4a56-bf46-a38a9c2232e9/ leads you to believe). I think I actually tried both those changes individually, but not both at o= nce. I'll test a patched build on Windows 7 tomorrow as well, sadly I don't have access to anything running Windows 95. Thanks for taking the time to look at this and test it. On 7 August 2012 04:53, Eli Zaretskii wrote: >> Date: Mon, 6 Aug 2012 22:20:01 +0200 >> From: Joakim H=E5rsman >> Cc: lekktu@gmail.com, 10299@debbugs.gnu.org >> >> Sorry for the late reply, I've been away on vacation. > > No sweat. Hope you had a good one. > >> 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 I change w32_set frame text to always call SetWindowText I get a >> default frame title of "e". Changing DispatchMessage to use the wide >> version when appropriate doesn't help either. > > I didn't see any problem with the frame title, with the patch I sent. > I'm curious to hear if you will still see that problem. > >> I'll try your new patch tomorrow and get back with details on how it wor= ked, > > Thank you. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Aug 2012 19:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jason Rumney Cc: lekktu@gmail.com, Eli Zaretskii , 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.134436947420592 (code B ref 10299); Tue, 07 Aug 2012 19:58:02 +0000 Received: (at 10299) by debbugs.gnu.org; 7 Aug 2012 19:57:54 +0000 Received: from localhost ([127.0.0.1]:40363 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sypub-0005M5-KQ for submit@debbugs.gnu.org; Tue, 07 Aug 2012 15:57:53 -0400 Received: from mail-yw0-f44.google.com ([209.85.213.44]:42294) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SypuY-0005Lx-HD for 10299@debbugs.gnu.org; Tue, 07 Aug 2012 15:57:51 -0400 Received: by yhq56 with SMTP id 56so4230828yhq.3 for <10299@debbugs.gnu.org>; Tue, 07 Aug 2012 12:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RdVvOHYTdQvnCIwMzeGDj27gI+sVjpnWpBAtTTSigsQ=; b=b43app5Y++x4g5/01LSKShO9/IljXJKf2amlasYvBr2x5IAfzUJScgL8QAZU1UUm0d hbJMx+KJhHNlaQHZZm8g2oZneZ+JlBuQHFHQXDIGTJHuTckGLAa9YTsD3guVb8vjNCEX rSCqP6cF1poVLYEvAcBdxuZUFort5zkU5hG72miLvk/rU+Q/4tQgXuZG0wIzSOivL43V B55Xy2hCLi/5EklUDVqMHqIOyQ7kvM51UdTC2a9FSuVrapZckx2m+0tcVdN3eUBUNW8u zvxEKdiVUPPTNfqWDeq28R/2lkV2AM72xr5vHYExXsEIboEvnFruBpSN+RP3NjIrxcW7 mFHg== MIME-Version: 1.0 Received: by 10.50.236.4 with SMTP id uq4mr9874616igc.18.1344368989727; Tue, 07 Aug 2012 12:49:49 -0700 (PDT) Received: by 10.50.45.70 with HTTP; Tue, 7 Aug 2012 12:49:49 -0700 (PDT) In-Reply-To: <87txweq4nx.fsf@gnu.org> References: <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> <836298hrdt.fsf@gnu.org> <87txweq4nx.fsf@gnu.org> Date: Tue, 7 Aug 2012 21:49:49 +0200 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) 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 wrote: > Joakim H=E5rsman 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 t= o >>> + retain compatibility with Windows 95. */ >>> + >>> +static void >>> +w32_set_frame_text (HWND hwnd, LPCSTR text) >>> +{ >>> + if (os_subtype =3D=3D 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 =3D ENCODE_SYSTEM (name); >>> - >>> + name =3D 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 u= sing > this patch. > > From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Aug 2012 02:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Cc: lekktu@gmail.com, 10299@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.134439460324974 (code B ref 10299); Wed, 08 Aug 2012 02:57:01 +0000 Received: (at 10299) by debbugs.gnu.org; 8 Aug 2012 02:56:43 +0000 Received: from localhost ([127.0.0.1]:40814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SywRv-0006Uk-CI for submit@debbugs.gnu.org; Tue, 07 Aug 2012 22:56:43 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:45998) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SywRr-0006UX-EJ for 10299@debbugs.gnu.org; Tue, 07 Aug 2012 22:56:40 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M8F007000YZYQ00@a-mtaout21.012.net.il> for 10299@debbugs.gnu.org; Wed, 08 Aug 2012 05:48:36 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M8F0071514ZRBA0@a-mtaout21.012.net.il>; Wed, 08 Aug 2012 05:48:36 +0300 (IDT) Date: Wed, 08 Aug 2012 05:48:37 +0300 From: Eli Zaretskii In-reply-to: Message-id: <83ehnif69m.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> <836298hrdt.fsf@gnu.org> <83ehnj9zva.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Tue, 7 Aug 2012 21:47:38 +0200 > From: Joakim H=E5rsman > Cc: lekktu@gmail.com, 10299@debbugs.gnu.org >=20 > Your patch works fine for me on Windows XP. Unicode input outside t= he > system code page works fine and so does non-ASCII input that is > present in the current code page. Great. > I'll test a patched build on Windows 7 tomorrow as well Thanks. > sadly I don't have access to anything running Windows 95. Neither do I, but then the new code is not activated on Windows 9X, o= r at least isn't supposed to be. From unknown Sat Jun 21 05:18:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Resent-From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Aug 2012 19:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10299 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: lekktu@gmail.com, 10299@debbugs.gnu.org Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.134445252927437 (code B ref 10299); Wed, 08 Aug 2012 19:03:01 +0000 Received: (at 10299) by debbugs.gnu.org; 8 Aug 2012 19:02:09 +0000 Received: from localhost ([127.0.0.1]:42837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzBWC-00078T-FF for submit@debbugs.gnu.org; Wed, 08 Aug 2012 15:02:09 -0400 Received: from mail-gg0-f172.google.com ([209.85.161.172]:50581) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzBWB-00078N-6F for 10299@debbugs.gnu.org; Wed, 08 Aug 2012 15:02:07 -0400 Received: by ggnh4 with SMTP id h4so97062ggn.3 for <10299@debbugs.gnu.org>; Wed, 08 Aug 2012 11:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wPnCDxAF5gctFZGYPIcqtxPP6Wf5SkVPITCynfHz094=; b=Bey/Q6bXG1XhrW63bi5aRAyDfrxj3efu8f/S54IzlTK6GjT4KmLJ13NpLI8bLgep/e v3LECUV2yurOVBgnhHVUZyHcA8sLlfCt69VCMaDG4WG+weKAEMRZLuJf0+lNxdWKqtxQ b98V5wZrwb7p6JfK2kLN2cyKgj/mtAUDw8+ft9m+J8AACb3QvtiXpOMSxVUPOc2u9OtF F9t2NZIyQifqidRdUeB1y4Mh1ORA3iiHJJFpXJWXQ8EG5OkmXUXf6NdzF+ssSySKLN3a TdxYFyIkcuDcsl50bxO5koTutDVq1dxTrJXSU7LKrnABofX+Z92HtxbqatLEgenikyk2 epYA== MIME-Version: 1.0 Received: by 10.50.236.65 with SMTP id us1mr2002407igc.17.1344452040305; Wed, 08 Aug 2012 11:54:00 -0700 (PDT) Received: by 10.50.6.136 with HTTP; Wed, 8 Aug 2012 11:54:00 -0700 (PDT) In-Reply-To: <83ehnif69m.fsf@gnu.org> References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> <836298hrdt.fsf@gnu.org> <83ehnj9zva.fsf@gnu.org> <83ehnif69m.fsf@gnu.org> Date: Wed, 8 Aug 2012 20:54:00 +0200 Message-ID: From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Works fine on Windows 7 as well. On 8 August 2012 04:48, Eli Zaretskii wrote: >> Date: Tue, 7 Aug 2012 21:47:38 +0200 >> From: Joakim H=E5rsman >> Cc: lekktu@gmail.com, 10299@debbugs.gnu.org >> >> Your patch works fine for me on Windows XP. Unicode input outside the >> system code page works fine and so does non-ASCII input that is >> present in the current code page. > > Great. > >> I'll test a patched build on Windows 7 tomorrow as well > > Thanks. > >> sadly I don't have access to anything running Windows 95. > > Neither do I, but then the new code is not activated on Windows 9X, or > at least isn't supposed to be. From unknown Sat Jun 21 05:18:07 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Joakim =?UTF-8?Q?H=C3=A5rsman?= Subject: bug#10299: closed (Re: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows) Message-ID: References: <83boijdyl8.fsf@gnu.org> X-Gnu-PR-Message: they-closed 10299 X-Gnu-PR-Package: emacs Reply-To: 10299@debbugs.gnu.org Date: Fri, 10 Aug 2012 07:05:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1344582302-12997-1" This is a multi-part message in MIME format... ------------=_1344582302-12997-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Wi= ndows which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 10299@debbugs.gnu.org. --=20 10299: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D10299 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1344582302-12997-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 10299-done) by debbugs.gnu.org; 10 Aug 2012 07:04:48 +0000 Received: from localhost ([127.0.0.1]:45876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzjH6-0003ND-69 for submit@debbugs.gnu.org; Fri, 10 Aug 2012 03:04:48 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:60975) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzjH2-0003N4-V0 for 10299-done@debbugs.gnu.org; Fri, 10 Aug 2012 03:04:46 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M8J00B001UVV400@a-mtaout22.012.net.il> for 10299-done@debbugs.gnu.org; Fri, 10 Aug 2012 09:56:29 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M8J00BYX1Y5KG50@a-mtaout22.012.net.il>; Fri, 10 Aug 2012 09:56:29 +0300 (IDT) Date: Fri, 10 Aug 2012 09:56:35 +0300 From: Eli Zaretskii Subject: Re: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows In-reply-to: To: Joakim =?iso-8859-1?Q?H=E5rsman?= Message-id: <83boijdyl8.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> <83obv821wv.fsf@gnu.org> <831us31atj.fsf@gnu.org> <83pqflzr1d.fsf@gnu.org> <836298hrdt.fsf@gnu.org> <83ehnj9zva.fsf@gnu.org> <83ehnif69m.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 10299-done Cc: lekktu@gmail.com, 10299-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Wed, 8 Aug 2012 20:54:00 +0200 > From: Joakim H=E5rsman > Cc: lekktu@gmail.com, 10299@debbugs.gnu.org >=20 > Works fine on Windows 7 as well. Great, I committed the changes as trunk revision 109542. ------------=_1344582302-12997-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 14 Dec 2011 20:41:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RavdO-0008BU-Fu for submit@debbugs.gnu.org; Wed, 14 Dec 2011 15:41:03 -0500 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RavdM-0008B6-0u for submit@debbugs.gnu.org; Wed, 14 Dec 2011 15:41:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ravbw-0001P9-W2 for submit@debbugs.gnu.org; Wed, 14 Dec 2011 15:39:34 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:36328) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ravbw-0001P5-TL for submit@debbugs.gnu.org; Wed, 14 Dec 2011 15:39:32 -0500 Received: from eggs.gnu.org ([140.186.70.92]:44217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ravbv-0002e0-P2 for bug-gnu-emacs@gnu.org; Wed, 14 Dec 2011 15:39:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ravbu-0001Oo-Mx for bug-gnu-emacs@gnu.org; Wed, 14 Dec 2011 15:39:31 -0500 Received: from mail-ey0-f169.google.com ([209.85.215.169]:43595) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ravbu-0001Ok-EK for bug-gnu-emacs@gnu.org; Wed, 14 Dec 2011 15:39:30 -0500 Received: by eaai13 with SMTP id i13so1447940eaa.0 for ; Wed, 14 Dec 2011 12:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Mtsj49P4Y7HgJbm0BRy+7OJZlpJDuNOTB/IHCn41ED4=; b=EGIQnWvGMIP1oNeLnbtGxad6dR17bpTpE3ygUiZ4GTg7Rf1kG+H50sV5jT4s2JA84C rszIqAwsqbQsvvmCeJxQWSsCV1Ann66CUc1VcqP0Dye7Har45Tlj2i6fjYgRA4Nezlr2 zROeSAHZgPgL28MaDYiPZCLKzxJ5VAKeLn4zY= MIME-Version: 1.0 Received: by 10.205.125.144 with SMTP id gs16mr21976bkc.137.1323895168962; Wed, 14 Dec 2011 12:39:28 -0800 (PST) Received: by 10.205.40.130 with HTTP; Wed, 14 Dec 2011 12:39:28 -0800 (PST) Date: Wed, 14 Dec 2011 21:39:28 +0100 Message-ID: Subject: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows From: =?ISO-8859-1?Q?Joakim_H=E5rsman?= To: bug-gnu-emacs Content-Type: text/plain; charset=ISO-8859-1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.6 (-----) In MS Windows, users can easily create custom keyboard layouts using Microsoft Keyboard Creator [1]. This can be used to for example to make typing certain Unicode symbols easier (like Greek letters when typing mathematical formula), and is very useful. However, Emacs doesn't seem to handle the case when the keyboard layout contains characters not available in the ANSI code page, and just prints a question mark character instead. For certain characters, a character that is visually similar to the actual character is printed instead of a question mark. For example, if I use a layout where AltGr+O produces U+2218 RING OPERATOR, Emacs prints U+00B0 DEGREE SYMBOL instead. The degree symbol is available in Windows 1252, the default ANSI code page on my system, but the ring operator isn't. However, if the layout maps AltGr+R to U+0220A SMALL ELEMENT OF, Emacs just prints a question mark, presumably because Windows 1252 doesn't contain a reasonable replacement for that character. I can reproduce this on Emacs 24.0.92.1 (i386-mingw-nt5.1.2600) even when started with -q to skip any customization. I'd be happy to help debug this but I have no idea where to even start. Is there an easy way to find out if it's the C code that clobbers the character or if it happens in lisp for example? [1]: http://msdn.microsoft.com/en-us/goglobal/bb964665 ------------=_1344582302-12997-1--