From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joakim =?UTF-8?Q?H=C3=A5rsman?= Newsgroups: gmane.emacs.bugs Subject: bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows Date: Fri, 16 Dec 2011 12:01:02 +0100 Message-ID: References: <8739clgapc.fsf@gnu.org> <83zket20xw.fsf@gnu.org> <83vcph0w9t.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1324033309 20167 80.91.229.12 (16 Dec 2011 11:01:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2011 11:01:49 +0000 (UTC) Cc: 10299@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 16 12:01:44 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RbVXn-00087D-W7 for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 Dec 2011 12:01:40 +0100 Original-Received: from localhost ([::1]:37550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbVXn-0006ok-J0 for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 Dec 2011 06:01:39 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:33366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbVXg-0006oP-5l for bug-gnu-emacs@gnu.org; Fri, 16 Dec 2011 06:01:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbVXb-00029t-Mp for bug-gnu-emacs@gnu.org; Fri, 16 Dec 2011 06:01:32 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbVXb-00029n-H7 for bug-gnu-emacs@gnu.org; Fri, 16 Dec 2011 06:01:27 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RbVZ8-0004oq-1d for bug-gnu-emacs@gnu.org; Fri, 16 Dec 2011 06:03:02 -0500 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 10299-submit@debbugs.gnu.org id=B10299.132403336118489 (code B ref 10299); Fri, 16 Dec 2011 11:03:01 +0000 Original-Received: (at 10299) by debbugs.gnu.org; 16 Dec 2011 11:02:41 +0000 Original-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 Original-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 Original-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= Original-Received: by 10.205.129.148 with SMTP id hi20mr2759442bkc.25.1324033262892; Fri, 16 Dec 2011 03:01:02 -0800 (PST) Original-Received: by 10.204.58.209 with HTTP; Fri, 16 Dec 2011 03:01:02 -0800 (PST) In-Reply-To: <83vcph0w9t.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 16 Dec 2011 06:03:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:55007 Archived-At: 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.