two different internal representations of the key

two different internal representations of the key

[Gour]

[-- Attachment #1: Type: text/plain, Size: 2816 bytes --]

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

One of the emacs' selling point is ability to rebind the keyboard to suit the editor for non-us layout.

Based on the hints from #emacs users, I tried to bind C-š to C-a, i.e. added the following line to my ~/.emacs:

(global-set-key (kbd "C-š") 'move-beginning-of-line)

If I ask help on C-a, C-h k C-a says: It is bound to C-a, C-š, <home>.

However,  C-h k C-š says:  C-š is undefined.

By reporting the issue in #emacs, i got help from 'fledermaus' who told me the problem is:

"there are two differnet internal representations, and they are not being used consistently." 

Moreover he hinted me to report "(kbd "C-š") is generating one vector for the key, which shows 
up when getting the help from the function, but actually pressing the key in X generates a different 
vector."

We went further th proof the problem:

 M-: (kbd "š") RET evaluates to: [331937]

By modifying ' describe-key' source (credit to fledermaus) with adding the line

    (fset 'yank-menu (cons 'keymap yank-menu))))))  
+  (message "KEY: %S" key)
    (if (numberp untranslated)

and issuing:

M-x describe-key RET C-š RET

evaluates:  KEY: [67111225]

otoh, M-: (kbd "C-š") RET

gives:  [67440801]

which confirms the problem that "kbd is supposed to be the one thing that tells you the canonical internal 
representation of any symbolic key representation,  which is different to eg. describe-key C-š" and therefore wrong.

Please, if someone can take a look on this issue, it's one of big advantages of emacs over vim for non-US users!

Sincerely,
Gour


In GNU Emacs 22.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.10.12)
 of 2007-06-08 on ovide
Windowing system distributor `The X.Org Foundation', version 11.0.10400000
configured using `configure  '--prefix=/usr' '--sysconfdir=/etc' '--libexecdir=/usr/lib' '--localstatedir=/var' '--mandir=/usr/man' '--without-sound' '-with-x-toolkit=gtk' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MESSAGES: en_US.UTF-8
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: identity


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: two different internal representations of the key

[Michael Schierl]

Hello,

On Wed, 21 Nov 2007 15:35:33 +0100, in gmane.emacs.bugs you wrote:

> Please, if someone can take a look on this issue, it's one of big
> advantages of emacs over vim for non-US users!

unfortunately this is an old and known issue (since Emacs 20 at least), and
I for myself have several "hacks" in my .emacs to work around it.

First:

(defun mihi-insert-keycode () 
  (interactive)
  (insert (format "%S" (read-key-sequence ""))))

This enables me to run M-x mihi-insert-keycode, press a key and have the
keycode in the current buffer. Then I have a cond block that defines keys
depending on system-configuration and/or window-system, like this:

(cond
 ((eq system-configuration 'windows-nt)
  (global-set-key [342387] "»")  ; C-ö
  (global-set-key [342398] "«")) ; C-ä
 ;; other configurations I use are here
)

Most likely this issue will vanish with Emacs 23, because that one will use
Unicode internally, so there won't be more than one codepoint for the same
character any longer.

Michael

-- 
#!/usr/bin/perl -I' # tekscribble.pl - start in an xterm and scribble with mouse
$|=1;$g="\35";sub g{getc}sub p{print@_}system"stty -icanon";p"\233?38h";for(;;){
p"$g\33\32";$_=g;$x=g;$X=g;$y=g;$Y=g;last if/q/;$k=$y.chr((ord$Y)+64).$x.chr((
ord$X)+32);p"\33\14"if/c/;p$g.(/ì/?$l:$k).$k;$l=$k;}p"\33\3";system"stty icanon"

Re: two different internal representations of the key

[Gour]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

On Sun, 25 Nov 2007 02:22:30 +0100
Michael Schierl <schierlm-usenet@gmx.de> wrote:

> unfortunately this is an old and known issue (since Emacs 20 at
> least)

[...] 

> Most likely this issue will vanish with Emacs 23, because that one
> will use Unicode internally, so there won't be more than one
> codepoint for the same character any longer.

Thanks a lot...

I was trying v23-cvs in order to see how will emacs with upcoming xft support look like, but then reverted
to stable v22.

However, building and trying out V23 (unicode-2 branch) I see that the problem is over :-)

Wonderful and let's dive into learning emacs now ;)


Sincerely,
Gour


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]