GNU bug report logs - #12082
24.1.50; Wrong character showed by "C-h c"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12082 in the body.
You can then email your comments to 12082 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.1.50; Wrong character showed by "C-h c"
Date: Sun, 29 Jul 2012 19:50:09 +0200

Hi,

With the current Emacs trunk, and from "emacs -Q", if I type "C-h c
M-ç", I get the message "M-‡ is undefined" in the echo area.

The correct message would be "M-ç is undefined", which is what I get
if I repeat the experiment with the Emacs 24.1 release.

However, if I repeat the experiment (both with the trunk and with the
24.1 release), but this time in TTY mode (-Q -nw), the version which
behaves correctly is the trunk (Emacs 24.1 gives me the message
"M-‡\207 is undefined").


In GNU Emacs 24.1.50.1 (i386-mingw-nt6.1.7601)
 of 2012-07-29 on DANI-PC
Bzr revision: 109266 eggert <at> cs.ucla.edu-20120729162923-a49hje8jpmssdozp
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -I../../libs/libiconv-1.14-2-mingw32-dev/include
 -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2
 -I../../libs/giflib-4.1.4-1/include
 -I../../emacs/libs/gnutls-3.0.16/include -I../../libs/jpeg-6b-4/include
 -I../../libs/libpng-1.4.10 -I../../libs/libxpm-3.5.8/include
 -I../../libs/libxpm-3.5.8/src -I../../libs/tiff-3.8.2-1/include
 -I../../libs/zlib-1.2.6'

Important settings:
  value of $EMACSDATA: C:/emacs/trunk/etc
  value of $EMACSDOC: C:/emacs/trunk/etc
  value of $EMACSLOADPATH: C:/emacs/trunk/lisp;C:/emacs/trunk/leim
  value of $EMACSPATH: C:/emacs/trunk/bin
  value of $LANG: ESN
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-h c M-‡ M-x r e p o r t SPC e SPC b SPC <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
M-‡ is undefined

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer button faces cus-face files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process multi-tty emacs)


-- 
Dani Moncayo

Message #8 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Sun, 29 Jul 2012 21:31:49 +0300

> Date: Sun, 29 Jul 2012 19:50:09 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> 
> With the current Emacs trunk, and from "emacs -Q", if I type "C-h c
> M-ç", I get the message "M-‡ is undefined" in the echo area.
> 
> The correct message would be "M-ç is undefined", which is what I get
> if I repeat the experiment with the Emacs 24.1 release.

This subtlety is the result of (not entirely correct) fix for
non-ASCII display on TTY.  Should be fixed now (trunk version 109272).

Message #11 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Sun, 29 Jul 2012 23:44:18 +0200

>> With the current Emacs trunk, and from "emacs -Q", if I type "C-h c
>> M-ç", I get the message "M-‡ is undefined" in the echo area.
>>
>> The correct message would be "M-ç is undefined", which is what I get
>> if I repeat the experiment with the Emacs 24.1 release.
>
> This subtlety is the result of (not entirely correct) fix for
> non-ASCII display on TTY.  Should be fixed now (trunk version 109272).

I've update my trunk branch (I have bzr revno 109274) and rebuilt Emacs.

Now I observe these messages from "Emacs -Q":
* C-h c M-ç => "M-‡ is undefined". (wrong, as before)
* C-h c ESC ç => "M-g (translated from <escape> ç) is undefined".
(wrong, should be "M-ç ...")

And from "Emacs -Q -nw":
* C-h c M-ç => "M-ç is undefined" (correct).
* C-h c ESC ç => "M-g (translated from <escape> ç) is undefined"
(wrong, as in the GUI session).


Juanma, could you please test this, and tell if you see the same?

Thanks.

-- 
Dani Moncayo

Message #14 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 01:04:34 +0200

On Sun, Jul 29, 2012 at 11:44 PM, Dani Moncayo <dmoncayo <at> gmail.com> wrote:

> Juanma, could you please test this, and tell

Yes.

> if you see the same?

Not the same.

> * C-h c M-ç => "M-‡ is undefined".

I see "M-ç is undefined" in both cases.

> * C-h c ESC ç => "M-g (translated from <escape> ç) is undefined".

I see this message in both cases.

    Juanma

Message #17 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 12082 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 06:37:23 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 30 Jul 2012 01:04:34 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 12082 <at> debbugs.gnu.org
> 
> On Sun, Jul 29, 2012 at 11:44 PM, Dani Moncayo <dmoncayo <at> gmail.com> wrote:
> 
> > Juanma, could you please test this, and tell
> 
> Yes.
> 
> > if you see the same?
> 
> Not the same.
> 
> > * C-h c M-ç => "M-‡ is undefined".
> 
> I see "M-ç is undefined" in both cases.

Interesting.  How did you two type M-ç?  And what are your values of
keyboard and terminal coding-systems, and also what does
w32-get-console-codepage return?

And Dani, if you go to the *Messages* buffer and type "C-u C-x =" with
the cursor on the ‡ character, what does Emacs say?

Message #20 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 11:17:06 +0200

> Interesting.  How did you two type M-ç?

In the spanish keyboard (the one I have) there is a key for each of
those two characters ("M" and "ç"), so M-ç is simply hold down the "M"
(alt) key and then press the "ç" key.

>  And what are your values of
> keyboard and terminal coding-systems, and also what does
> w32-get-console-codepage return?

In a GUI session of my trunk build (started with -Q):

  (keyboard-coding-system) => iso-latin-1-unix
  (terminal-coding-system) => cp1252
  (w32-get-console-codepage) => 850

> And Dani, if you go to the *Messages* buffer and type "C-u C-x =" with
> the cursor on the ‡ character, what does Emacs say?

It says this:

             position: 78 of 91 (85%), column: 2
            character: ‡ (displayed as ‡) (codepoint 8225, #o20041, #x2021)
    preferred charset: unicode (Unicode (ISO10646))
code point in charset: 0x2021
               syntax: _ 	which means: symbol
             category: .:Base, h:Korean, j:Japanese
             to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME"
          buffer code: #xE2 #x80 #xA1
            file code: not encodable by coding system iso-latin-1-dos
              display: by this font (glyph code)
    uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso10646-1 (#xC1)

Character code properties: customize what to show
  name: DOUBLE DAGGER
  general-category: Po (Punctuation, Other)
  decomposition: (8225) ('‡')


-- 
Dani Moncayo

Message #23 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 16:22:02 +0200

> I've update my trunk branch (I have bzr revno 109274) and rebuilt Emacs.
>
> Now I observe these messages from "Emacs -Q":
> * C-h c M-ç => "M-‡ is undefined". (wrong, as before)
> * C-h c ESC ç => "M-g (translated from <escape> ç) is undefined".
> (wrong, should be "M-ç ...")
>
> And from "Emacs -Q -nw":
> * C-h c M-ç => "M-ç is undefined" (correct).
> * C-h c ESC ç => "M-g (translated from <escape> ç) is undefined"
> (wrong, as in the GUI session).

I've just built the current trunk (r109294) because Andreas committed
a change (r109291) that could affect to this bug.  And something has
changed indeed.  Now I see:

from "emacs -Q":
1. C-h c M-ç => "M-‡ is undefined". (wrong, as before)
2. C-h c ESC ç => "M-ç (translated from <escape> ç) is undefined".  (correct)

and from "emacs -Q -nw":
3. C-h c M-ç => "M-ç is undefined" (correct).
4. C-h c ESC ç => "M-ç (translated from <escape> ç) is undefined".  (correct)

So the only problem is now in the test #1.

HTH.

-- 
Dani Moncayo

Message #26 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>, Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 17:32:23 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 30 Jul 2012 13:47:44 +0200
> 
> On Mon, Jul 30, 2012 at 5:37 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > Interesting.  How did you two type M-ç?  And what are your values of
> > keyboard and terminal coding-systems, and also what does
> > w32-get-console-codepage return?
> 
> Ah, now I see a difference. Interesting, yes.
> 
> I did the last check from a TCC console, not CMD, the difference being
> that in TCC I set the codepage to 1252, while CMD uses 850.
> 
> So yes, starting emacs from CMD in window mode, C-h c M-ç indeed
> produces the ‡ message.
> 
> I type M-ç with the left Alt key and the ç key of the Spanish keyboard.
> 
> So, to summarize:
> 
> - In CMD, with active codepage = 437
>   - Window mode:
>     keyboard-coding-system = windows-1252-unix
>     (terminal-coding-system) =  cp1252
>     (w32-get-console-codepage) = 437
>     Messages: "M-‡ is undefined"
> 
>   - Non-window mode:
>     keyboard-coding-system = cp437-unix
>     (terminal-coding-system) = cp437
>     (w32-get-console-codepage) = 437
>     Messages: "M-ç is undefined"
> 
> - In CMD, with active codepage = 850
> 
>   - Window mode:
>     keyboard-coding-system = windows-1252-unix
>     (terminal-coding-system) = cp1252
>     (w32-get-console-codepage) = 850
>     Message: "M-‡ is undefined"
> 
>   - Non-window mode:
>     keyboard-coding-system = cp850-unix
>     (terminal-coding-system) = cp850
>     (w32-get-console-codepage) = 850
>     Message: "M-ç is undefined"
> 
> - In CMD, with active codepage = 1252
> 
>   - Window mode:
>     keyboard-coding-system = windows-1252-unix
>     (terminal-coding-system) = cp1252
>     (w32-get-console-codepage) = 1252
>     Message: "M-ç is undefined"
> 
>   - Non-window mode:
>     keyboard-coding-system = windows-1252-unix
>     (terminal-coding-system) = cp1252
>     (w32-get-console-codepage) = 1252
>     Message: "M-ç is undefined"

Looks like Windows lies to us about the input codepage.  Please apply
the patches below, run Emacs in GUI mode under GDB, and do the
following experiments:

  . switch the keyboard to English ("EN" near the system tray), if you
    can, and type a couple of pure ASCII characters

  . switch the keyboard to Spanish and type ç and M-ç

  . do the latter both with active codepage 850 and 1252

In each case, show the DebPrint messages shown by GDB as result of
typing each character.

Thanks.


=== modified file 'src/w32fns.c'
--- src/w32fns.c	2012-07-29 08:18:29 +0000
+++ src/w32fns.c	2012-07-30 14:06:20 +0000
@@ -2918,6 +2918,7 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARA
 
     case WM_SYSCHAR:
     case WM_CHAR:
+      DebPrint (("w32fns: WM_CHAR 0x%x\n", wParam));
       post_character_message (hwnd, msg, wParam, lParam,
 			      w32_get_key_modifiers (wParam, lParam));
       break;
@@ -2939,6 +2940,7 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARA
 
       {
         W32Msg wmsg;
+	DebPrint (("w32fns: WM_UNICHAR 0x%x\n", wParam));
         wmsg.dwModifiers = w32_get_key_modifiers (wParam, lParam);
         signal_user_input ();
         my_post_msg (&wmsg, hwnd, msg, wParam, lParam);

=== modified file 'src/w32term.c'
--- src/w32term.c	2012-07-29 08:18:29 +0000
+++ src/w32term.c	2012-07-30 14:07:21 +0000
@@ -4295,6 +4295,7 @@ w32_read_socket (struct terminal *termin
 
               if (msg.msg.message == WM_UNICHAR)
                 {
+		  DebPrint (("w32term: WM_UNICHAR 0x%x\n", msg.msg.wParam));
                   inev.code = msg.msg.wParam;
                 }
               else if (msg.msg.wParam < 256)
@@ -4336,6 +4337,9 @@ w32_read_socket (struct terminal *termin
                           break;
                         }
                     }
+
+		  DebPrint (("w32term: 0x%x => 0x%x (cp%d)\n",
+			     (char) msg.msg.wParam, code, keyboard_codepage));
                   inev.code = code;
                 }
               else

Message #29 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 16:32:44 +0200

On Mon, Jul 30, 2012 at 4:22 PM, Dani Moncayo <dmoncayo <at> gmail.com> wrote:

> I've just built the current trunk (r109294) because Andreas committed
> a change (r109291) that could affect to this bug.

Yes, I saw Eli's bug report and Andreas' commit and assumed it fixed
the second problem, but I haven't had the time to try it. Thanks for
checking.

    Juanma

Message #32 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: lekktu <at> gmail.com, 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 17:37:24 +0300

> Date: Mon, 30 Jul 2012 16:22:02 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: 12082 <at> debbugs.gnu.org, Juanma Barranquero <lekktu <at> gmail.com>
> 
> So the only problem is now in the test #1.

It always was.  What Andreas fixed was only the key-description part.
The problem with actually inputting the wrong codepoint remains.

Message #35 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12082 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 16:49:06 +0200

On Mon, Jul 30, 2012 at 4:32 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

>   . switch the keyboard to English ("EN" near the system tray), if you
>     can, and type a couple of pure ASCII characters

- With english keyboard

a
warning: w32fns: WM_CHAR 0x61
warning: w32term: 0x61 => 0x61 (cp1252)

$
warning: w32fns: WM_CHAR 0x24
warning: w32term: 0x24 => 0x24 (cp1252)

;
warning: w32fns: WM_CHAR 0x3b
warning: w32term: 0x3b => 0x3b (cp1252)

>   . switch the keyboard to Spanish and type ç and M-ç

- With spanish keyboard, cp 850:

ç
warning: w32fns: WM_CHAR 0xe7
warning: w32term: 0xffffffe7 => 0xe7 (cp1252)

M-ç
warning: w32term: 0xffffff87 => 0x2021 (cp1252)

- With spanish keyboard, cp 1252

ç
warning: w32fns: WM_CHAR 0xe7
warning: w32term: 0xffffffe7 => 0xe7 (cp1252)

M-ç
warning: w32term: 0xffffffe7 => 0xe7 (cp1252)


    Juanma

Message #38 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 16:53:38 +0200

> Looks like Windows lies to us about the input codepage.  Please apply
> the patches below, run Emacs in GUI mode under GDB, and do the
> following experiments:
>
>   . switch the keyboard to English ("EN" near the system tray), if you
>     can, and type a couple of pure ASCII characters

[a]
warning: w32fns: WM_CHAR 0x61
warning: w32term: 0x61 => 0x61 (cp1252)

[z]
warning: w32fns: WM_CHAR 0x7a
warning: w32term: 0x7a => 0x7a (cp1252)

>   . switch the keyboard to Spanish and type ç and M-ç

[ç]
warning: w32fns: WM_CHAR 0xe7
warning: w32term: 0xffffffe7 => 0xe7 (cp1252)

[M-ç]
warning: w32term: 0xffffff87 => 0x2021 (cp1252)

(yes, only one message for this character)

>   . do the latter both with active codepage 850 and 1252

?? Where can I set the "active codepage"? Please elaborate this step a bit more.

-- 
Dani Moncayo

Message #41 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 16:56:53 +0200

On Mon, Jul 30, 2012 at 4:53 PM, Dani Moncayo <dmoncayo <at> gmail.com> wrote:

> ?? Where can I set the "active codepage"? Please elaborate this step a bit more.

Use the chcp command in the CMD session before running gdb / emacs.

    Juanma

Message #44 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 17:05:01 +0200

>>   . switch the keyboard to English ("EN" near the system tray), if you
>>     can, and type a couple of pure ASCII characters
>
> [a]
> warning: w32fns: WM_CHAR 0x61
> warning: w32term: 0x61 => 0x61 (cp1252)
>
> [z]
> warning: w32fns: WM_CHAR 0x7a
> warning: w32term: 0x7a => 0x7a (cp1252)
>
>>   . switch the keyboard to Spanish and type ç and M-ç
>
> [ç]
> warning: w32fns: WM_CHAR 0xe7
> warning: w32term: 0xffffffe7 => 0xe7 (cp1252)
>
> [M-ç]
> warning: w32term: 0xffffff87 => 0x2021 (cp1252)
>
> (yes, only one message for this character)
>
>>   . do the latter both with active codepage 850 and 1252

(Thanks Juanma)

All the above was with codepage 850.  Now if I set the codepage to
1252 (in the cmd sessions from where I invoke gdb and Emacs), I see:

[ç]
warning: w32fns: WM_CHAR 0xe7
warning: w32term: 0xffffffe7 => 0xe7 (cp1252)

[M-ç]
warning: w32term: 0xffffffe7 => 0xe7 (cp1252)


-- 
Dani Moncayo

Message #47 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: lekktu <at> gmail.com, 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 18:58:44 +0300

> Date: Mon, 30 Jul 2012 17:05:01 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: Juanma Barranquero <lekktu <at> gmail.com>, 12082 <at> debbugs.gnu.org
> 
> >>   . switch the keyboard to English ("EN" near the system tray), if you
> >>     can, and type a couple of pure ASCII characters
> >
> > [a]
> > warning: w32fns: WM_CHAR 0x61
> > warning: w32term: 0x61 => 0x61 (cp1252)
> >
> > [z]
> > warning: w32fns: WM_CHAR 0x7a
> > warning: w32term: 0x7a => 0x7a (cp1252)
> >
> >>   . switch the keyboard to Spanish and type ç and M-ç
> >
> > [ç]
> > warning: w32fns: WM_CHAR 0xe7
> > warning: w32term: 0xffffffe7 => 0xe7 (cp1252)
> >
> > [M-ç]
> > warning: w32term: 0xffffff87 => 0x2021 (cp1252)
> >
> > (yes, only one message for this character)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This means M-ç gets processed by some code in w32fns.c that doesn't
have a DebPrint.  Can you find out which one (by sticking DebPrint)?
For example, these two fragments look as possible suspects:

1)
	default:
	  /* If not defined as a function key, change it to a WM_CHAR message. */
	  if (wParam > 255 || !lispy_function_keys[wParam])
	    {
	      DWORD modifiers = construct_console_modifiers ();

            ...
	      else
		{
		  /* Let TranslateMessage handle everything else.  */
		  windows_translate = 1;
		}
	    }


2)
    translate:
      if (windows_translate)
	{
	  MSG windows_msg = { hwnd, msg, wParam, lParam, 0, {0,0} };
	  windows_msg.time = GetMessageTime ();
	  TranslateMessage (&windows_msg);
	  goto dflt;
	}

Can you stick a DebPrint into each block and see which one handles
M-ç?

Message #50 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 18:16:08 +0200

>> > [M-ç]
>> > warning: w32term: 0xffffff87 => 0x2021 (cp1252)
>> >
>> > (yes, only one message for this character)
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This means M-ç gets processed by some code in w32fns.c that doesn't
> have a DebPrint.  Can you find out which one (by sticking DebPrint)?
> For example, these two fragments look as possible suspects:
>
> 1)
>         default:

In this line, I inserted this: DebPrint (("w32fns: #1-default 0x%x\n", wParam));

>           /* If not defined as a function key, change it to a WM_CHAR message. */
>           if (wParam > 255 || !lispy_function_keys[wParam])


And I've seen that the execution arrives to this first case.  This is
the output from gdb:

  warning: w32fns: #1-default 0xbf
  warning: w32term: 0xffffff87 => 0x2021 (cp1252)


-- 
Dani Moncayo

Message #53 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: lekktu <at> gmail.com, 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 19:43:08 +0300

> Date: Mon, 30 Jul 2012 18:16:08 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: lekktu <at> gmail.com, 12082 <at> debbugs.gnu.org
> 
> >> > [M-ç]
> >> > warning: w32term: 0xffffff87 => 0x2021 (cp1252)
> >> >
> >> > (yes, only one message for this character)
> >           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > This means M-ç gets processed by some code in w32fns.c that doesn't
> > have a DebPrint.  Can you find out which one (by sticking DebPrint)?
> > For example, these two fragments look as possible suspects:
> >
> > 1)
> >         default:
> 
> In this line, I inserted this: DebPrint (("w32fns: #1-default 0x%x\n", wParam));
> 
> >           /* If not defined as a function key, change it to a WM_CHAR message. */
> >           if (wParam > 255 || !lispy_function_keys[wParam])
> 
> 
> And I've seen that the execution arrives to this first case.  This is
> the output from gdb:
> 
>   warning: w32fns: #1-default 0xbf
>   warning: w32term: 0xffffff87 => 0x2021 (cp1252)

Heh, everything is clear now.  Stay tuned for a solution.

Thanks.

Message #56 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: dmoncayo <at> gmail.com, lekktu <at> gmail.com
Cc: 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 20:16:17 +0300

> Date: Mon, 30 Jul 2012 19:43:08 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: lekktu <at> gmail.com, 12082 <at> debbugs.gnu.org
> 
> > Date: Mon, 30 Jul 2012 18:16:08 +0200
> > From: Dani Moncayo <dmoncayo <at> gmail.com>
> > Cc: lekktu <at> gmail.com, 12082 <at> debbugs.gnu.org
> > 
> > >> > [M-ç]
> > >> > warning: w32term: 0xffffff87 => 0x2021 (cp1252)
> > >> >
> > >> > (yes, only one message for this character)
> > >           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > This means M-ç gets processed by some code in w32fns.c that doesn't
> > > have a DebPrint.  Can you find out which one (by sticking DebPrint)?
> > > For example, these two fragments look as possible suspects:
> > >
> > > 1)
> > >         default:
> > 
> > In this line, I inserted this: DebPrint (("w32fns: #1-default 0x%x\n", wParam));
> > 
> > >           /* If not defined as a function key, change it to a WM_CHAR message. */
> > >           if (wParam > 255 || !lispy_function_keys[wParam])
> > 
> > 
> > And I've seen that the execution arrives to this first case.  This is
> > the output from gdb:
> > 
> >   warning: w32fns: #1-default 0xbf
> >   warning: w32term: 0xffffff87 => 0x2021 (cp1252)
> 
> Heh, everything is clear now.  Stay tuned for a solution.

Should be fixed in trunk revision 109300.  Please test.

Message #59 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 19:47:33 +0200

> Should be fixed in trunk revision 109300.  Please test.

Thank you so much.

The GUI session now seems to work like a charm.

The TTY session also works well for all the tests I've done so far,
but I've found another use case that seems an error: from "emacs -Q
-nw", if I type "C-h c C-ç", I get the message "C-\ runs the command
toggle-input-method".


FWIW, here are some values from the TTY session:
  (terminal-coding-system) => cp850
  (keyboard-coding-system) => cp850-unix
  w32-ansi-code-page => 1252
  (w32-get-console-codepage) => 850
  (w32-get-console-output-codepage) => 850

and when I exit emacs, the chcp command says "Active code page: 850".


-- 
Dani Moncayo

Message #62 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: lekktu <at> gmail.com, 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 21:11:53 +0300

> Date: Mon, 30 Jul 2012 19:47:33 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: lekktu <at> gmail.com, 12082 <at> debbugs.gnu.org
> 
> The TTY session also works well for all the tests I've done so far,
> but I've found another use case that seems an error: from "emacs -Q
> -nw", if I type "C-h c C-ç", I get the message "C-\ runs the command
> toggle-input-method".

That's probably a limitation of console input.  What happens if you
type C-ç alone, without "C-h c"?

Message #65 received at 12082 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 12082 <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 20:18:12 +0200

>>> The TTY session also works well for all the tests I've done so far,
>>> but I've found another use case that seems an error: from "emacs -Q
>>> -nw", if I type "C-h c C-ç", I get the message "C-\ runs the command
>>> toggle-input-method".
>>
>> That's probably a limitation of console input.  What happens if you
>> type C-ç alone, without "C-h c"?
>
> That the toggle-input-method command is executed (I see the change in
> the left part of the modeline).

And if I type C-ç directly in the cmd prompt, I see the text "^\"
inserted.  So it seems that the problem is outside emacs...


-- 
Dani Moncayo

Message #70 received at 12082-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: lekktu <at> gmail.com, 12082-done <at> debbugs.gnu.org
Subject: Re: bug#12082: 24.1.50; Wrong character showed by "C-h c"
Date: Mon, 30 Jul 2012 22:12:07 +0300

> Date: Mon, 30 Jul 2012 20:18:12 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: lekktu <at> gmail.com, 12082 <at> debbugs.gnu.org
> 
> >>> The TTY session also works well for all the tests I've done so far,
> >>> but I've found another use case that seems an error: from "emacs -Q
> >>> -nw", if I type "C-h c C-ç", I get the message "C-\ runs the command
> >>> toggle-input-method".
> >>
> >> That's probably a limitation of console input.  What happens if you
> >> type C-ç alone, without "C-h c"?
> >
> > That the toggle-input-method command is executed (I see the change in
> > the left part of the modeline).
> 
> And if I type C-ç directly in the cmd prompt, I see the text "^\"
> inserted.  So it seems that the problem is outside emacs...

Yep.  So I'm closing this bug.  Thanks for your help.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.