bug#12082: 24.1.50; Wrong character showed by "C-h c"

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Dani Moncayo]

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@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

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Eli Zaretskii]

> Date: Sun, 29 Jul 2012 19:50:09 +0200
> From: Dani Moncayo <dmoncayo@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).

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Dani Moncayo]

>> 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

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Juanma Barranquero]

On Sun, Jul 29, 2012 at 11:44 PM, Dani Moncayo <dmoncayo@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

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 30 Jul 2012 01:04:34 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, 12082@debbugs.gnu.org
> 
> On Sun, Jul 29, 2012 at 11:44 PM, Dani Moncayo <dmoncayo@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?

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Dani Moncayo]

> 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

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Dani Moncayo]

> 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

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 30 Jul 2012 13:47:44 +0200
> 
> On Mon, Jul 30, 2012 at 5:37 AM, Eli Zaretskii <eliz@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

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Juanma Barranquero]

On Mon, Jul 30, 2012 at 4:22 PM, Dani Moncayo <dmoncayo@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

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Eli Zaretskii]

> Date: Mon, 30 Jul 2012 16:22:02 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 12082@debbugs.gnu.org, Juanma Barranquero <lekktu@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.

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Juanma Barranquero]

On Mon, Jul 30, 2012 at 4:32 PM, Eli Zaretskii <eliz@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

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Dani Moncayo]

> 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

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Juanma Barranquero]

On Mon, Jul 30, 2012 at 4:53 PM, Dani Moncayo <dmoncayo@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

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Dani Moncayo]

>>   . 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

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Eli Zaretskii]

> Date: Mon, 30 Jul 2012 17:05:01 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Juanma Barranquero <lekktu@gmail.com>, 12082@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-ç?

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Dani Moncayo]

>> > [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

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Eli Zaretskii]

> Date: Mon, 30 Jul 2012 18:16:08 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: lekktu@gmail.com, 12082@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.

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Eli Zaretskii]

> Date: Mon, 30 Jul 2012 19:43:08 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: lekktu@gmail.com, 12082@debbugs.gnu.org
> 
> > Date: Mon, 30 Jul 2012 18:16:08 +0200
> > From: Dani Moncayo <dmoncayo@gmail.com>
> > Cc: lekktu@gmail.com, 12082@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.

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Dani Moncayo]

> 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

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Eli Zaretskii]

> Date: Mon, 30 Jul 2012 19:47:33 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: lekktu@gmail.com, 12082@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"?

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Dani Moncayo]

>>> 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

bug#12082: 24.1.50; Wrong character showed by "C-h c"

[Eli Zaretskii]

> Date: Mon, 30 Jul 2012 20:18:12 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: lekktu@gmail.com, 12082@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.