GNU bug report logs - #12090
24.1.50; "C-h c" mutilates M-c when c is a non-ASCII character

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 12090 in the body.
You can then email your comments to 12090 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: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.1.50; "C-h c" mutilates M-c when c is a non-ASCII character
Date: Mon, 30 Jul 2012 08:00:44 +0300

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgment at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

 emacs -Q
 C-h c ESC-ALEPH
   => M-Ր (translated from <escape> א) is undefined

(I type ALEPH by switching the keyboard to Hebrew.  With a hebrew
input method, I cannot produce META-ALEPH, I get M-t instead.  Maybe
it's a separate problem.)

Now, if I step through key-description, I see that the key arrives
there as [27 1488], which seems correct (1488 is 0x5d0, the Unicode
codepoint of ALEPH).  Then this fragment:

      else if (EQ (key, meta_prefix_char))
	{
	  add_meta = 1;
	  continue;
	}

correctly decides that META modifier should be applied.  But then this
fragment (see the line marked with "<<<<<<<"):

	  if (!INTEGERP (key)
	      || EQ (key, meta_prefix_char)
	      || (XINT (key) & meta_modifier))
	    {
	      args[len++] = Fsingle_key_description (meta_prefix_char, Qnil);
	      args[len++] = sep;
	      if (EQ (key, meta_prefix_char))
		continue;
	    }
	  else
	    XSETINT (key, (XINT (key) | meta_modifier) & ~0x80);  <<<<<<<<

resets the 0x80 bit of 0x5d0, converting it to 0x550 in the process,
which yields the Armenian character shown above.

Is this a bug, a feature, or what?

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
d:/gnu/bzr/emacs/trunk/etc/DEBUG.


In GNU Emacs 24.1.50.1 (i386-mingw-nt5.1.2600)
 of 2012-07-30 on HOME-C4E4A596F7
Bzr revision: 109283 dmantipov <at> yandex.ru-20120730040239-3fql4aq0pe97w1fh
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (3.4) --no-opt --enable-checking --cflags
 -Id:/usr/include/libxml2 -DGLYPH_DEBUG=1'

Important settings:
  value of $EMACSDATA: D:/gnu/bzr/emacs/trunk/etc
  value of $EMACSDOC: D:/gnu/bzr/emacs/trunk/etc
  value of $EMACSLOADPATH: D:/gnu/bzr/emacs/trunk/lisp;D:/gnu/bzr/emacs/trunk/leim
  value of $EMACSPATH: D:/gnu/bzr/emacs/trunk/bin
  value of $LANG: ENU
  locale-coding-system: cp1255
  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:
<help-echo> C-h c <escape> א <down> M-x r e p o r t 
- e m a <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
M-Ր (translated from <escape> א) is undefined
byte-code: End of buffer

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)

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12090-done <at> debbugs.gnu.org
Subject: Re: bug#12090: 24.1.50;
	"C-h c" mutilates M-c when c is a non-ASCII character
Date: Mon, 30 Jul 2012 09:51:21 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> But then this fragment (see the line marked with "<<<<<<<"):
>
> 	  if (!INTEGERP (key)
> 	      || EQ (key, meta_prefix_char)
> 	      || (XINT (key) & meta_modifier))
> 	    {
> 	      args[len++] = Fsingle_key_description (meta_prefix_char, Qnil);
> 	      args[len++] = sep;
> 	      if (EQ (key, meta_prefix_char))
> 		continue;
> 	    }
> 	  else
> 	    XSETINT (key, (XINT (key) | meta_modifier) & ~0x80);  <<<<<<<<
>
> resets the 0x80 bit of 0x5d0, converting it to 0x550 in the process,
> which yields the Armenian character shown above.

This was added in commit b042457 back in 2004, and is most likely
unintented.  Fixed in trunk.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 12090-done <at> debbugs.gnu.org
Subject: Re: bug#12090: 24.1.50;
	"C-h c" mutilates M-c when c is a non-ASCII character
Date: Mon, 30 Jul 2012 16:50:24 +0300

> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: 12090-done <at> debbugs.gnu.org
> Date: Mon, 30 Jul 2012 09:51:21 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > But then this fragment (see the line marked with "<<<<<<<"):
> >
> > 	  if (!INTEGERP (key)
> > 	      || EQ (key, meta_prefix_char)
> > 	      || (XINT (key) & meta_modifier))
> > 	    {
> > 	      args[len++] = Fsingle_key_description (meta_prefix_char, Qnil);
> > 	      args[len++] = sep;
> > 	      if (EQ (key, meta_prefix_char))
> > 		continue;
> > 	    }
> > 	  else
> > 	    XSETINT (key, (XINT (key) | meta_modifier) & ~0x80);  <<<<<<<<
> >
> > resets the 0x80 bit of 0x5d0, converting it to 0x550 in the process,
> > which yields the Armenian character shown above.
> 
> This was added in commit b042457 back in 2004, and is most likely
> unintented.  Fixed in trunk.

Thanks.

Previous Next

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