help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bind C-ε o C-e


From: James Cloos
Subject: Re: bind C-ε o C-e
Date: Thu, 17 Aug 2006 00:17:16 -0400
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.0 (gnu/linux)

>>>>> "Drosos" == A Drosos <drososa@otenet.gr> writes:

Drosos> I'm using emacs 22.0.50.1 build from source on a Linux from Scratch
Drosos> box. I'm  also editing text documents in the greek language. On the
Drosos> console, I can switch between greek/english with LeftAlt-Shift and
Drosos> still be able to use the  regular C-e and similar sequences to move
Drosos> around my document. This does not happen in X-windows. The message I
Drosos> get for C-ε (for example) and similar keys, is that they are undefined.

I see the same thing with emacs-23 (the unicode-2 branch from cvs).

xev(1x) shows this for C-α:

,----(xev keypress event)
| KeyPress event, serial 30, synthetic NO, window 0x1000001,
|     root 0x4c, subw 0x0, time 440539587, (134,152), root:(760,179),
|     state 0x4000, keycode 66 (keysym 0xffe3, Control_L), same_screen YES,
|     XKeysymToKeycode returns keycode: 37
|     XLookupString gives 0 bytes: 
|     XmbLookupString gives 0 bytes: 
|     XFilterEvent returns: False
| 
| KeyPress event, serial 30, synthetic NO, window 0x1000001,
|     root 0x4c, subw 0x0, time 440539762, (134,152), root:(760,179),
|     state 0x4004, keycode 38 (keysym 0x61, a), same_screen YES,
|     XLookupString gives 1 bytes: (01) ""
|     XmbLookupString gives 1 bytes: (01) ""
|     XFilterEvent returns: False
`----

vs this for just α:

,----(xev keypress event)
| KeyPress event, serial 30, synthetic NO, window 0x1000001,
|     root 0x4c, subw 0x0, time 440536069, (134,152), root:(760,179),
|     state 0x2000, keycode 38 (keysym 0x7e1, Greek_alpha), same_screen YES,
|     XLookupString gives 2 bytes: (ce b1) "α"
|     XmbLookupString gives 2 bytes: (ce b1) "α"
|     XFilterEvent returns: False
`----

Apps like rxvt-unicode see the “state 0x4004, keycode 38 (keysym 0x61 a)”
and generate a C-a, but apps like emacs and gvim end up with keysym 0x7e1
and end up inserting a α or complaining that C-α isn’t bound.

I can only presume that emacs, et al are setting filters and such to track
the modifier keys themselves rather than relying on XLookupString(3x) and
friends to do it.  Or that by filtering out the modifier keys XLookupString(),
et al return different results.

AFAICS emacs will require a patch to fix this issue.  Until then you
can run it in a terminal window (rxvt-unicode is my favourite for
running « emacs -nw », but xterm is also good) if the current situation
gets in the way.  I use emacs-23 and emacs-22 quite a lot over ssh; it is
just as useful as running it in X11-native mode, given an adequate term.

-JimC
-- 
James Cloos <cloos@jhcloos.com>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]