urxvt/xterm + vim, 4. Ebene Ziffern gehen nicht

[mail@…]

Ich benutze das neueste neo-layout. Wenn ich im Terminal urxvt oder xterm einen vim starte und dort eine Zahl über den integrierten Nummernblock der 4.Ebene (Leertaste, m,.nrthgf) eingeben möchte wird eine neue Zeile über der aktuellen angelegt und dort ein einzelner, kleiner Buchstabe geschrieben (pq...y) abgesehen von 3 und 9. Dort wird nur gescrollt. Bei 3/s nach unten und bei 9/y nach oben. Im Konsole-Terminal (KDE) passiert dieses Problem nicht. Auch bei anderen Anwendungen oder in der Kommandozeile in urxvt/xterm funktioniert alles prima. Das Problem wurde auch von anderen beobachtet.

xev-Ausgabe bei "4" auf der 4.Ebene:

KeyPress event, serial 34, synthetic NO, window 0x5600001,

root 0x329, subw 0x0, time 22545944, (-561,929), root:(1731,988), state 0x0, keycode 94 (keysym 0xfe11, ISO_Level5_Shift), same_screen YES, XKeysymToKeycode returns keycode: 93 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False

KeyPress event, serial 34, synthetic NO, window 0x5600001,

root 0x329, subw 0x0, time 22546188, (-561,929), root:(1731,988), state 0x20, keycode 44 (keysym 0xffb4, KP_4), same_screen YES, XKeysymToKeycode returns keycode: 83 XLookupString gives 1 bytes: (34) "4" XmbLookupString gives 1 bytes: (34) "4" XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x5600001,

root 0x329, subw 0x0, time 22546261, (-561,929), root:(1731,988), state 0x20, keycode 44 (keysym 0xffb4, KP_4), same_screen YES, XKeysymToKeycode returns keycode: 83 XLookupString gives 1 bytes: (34) "4" XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x5600001,

root 0x329, subw 0x0, time 22546650, (-561,929), root:(1731,988), state 0x20, keycode 94 (keysym 0xfe13, ISO_Level5_Lock), same_screen YES, XKeysymToKeycode returns keycode: 23 XLookupString gives 0 bytes: XFilterEvent returns: False

System: Gentoo Linux vim 7.2.182

[anonymous]

Ich sehe dieses Problem nicht nur mit dem Ebene 4-Ziffernblock, sondern auch mit dem echten, und nicht nur mit vim, sondern auch mit nvi.

Entweder werden die Keysyms nicht richtig in Steuersequenzen umgesetzt oder vim/nvi können mit den Steuersequenzen nicht umgehen. Falls sich jemand mit termcap und dergleichen auskennt könnte man in dieser Richtung weiterbohren; vielleicht muss man ja nur TERM geeignet setzen.

Hier zunächst einmal ein Vorschlag, das Problem für den echten Ziffernblock zu umgehen; der Ebene-4-Ziffernblock sollte sich ähnlich behandeln lasse (Da ich den offiziellen XKB-Treiber nicht verwende kann ich das nicht verifizieren)

Für urxvt schreibt man in die X-Resourcen (siehe die urxvt man page):

URxvt.keysym.KP_Add:    +
URxvt.keysym.KP_Subtract: -
URxvt.keysym.KP_Multiply: *
URxvt.keysym.KP_Divide  : /
URxvt.keysym.KP_Decimal : .
URxvt.keysym.KP_Separator : ,
URxvt.keysym.KP_1:      1
URxvt.keysym.KP_2:      2
URxvt.keysym.KP_3:      3
URxvt.keysym.KP_4:      4
URxvt.keysym.KP_5:      5
URxvt.keysym.KP_6:      6
URxvt.keysym.KP_7:      7
URxvt.keysym.KP_8:      8
URxvt.keysym.KP_9:      9
URxvt.keysym.KP_0:      0

Für xterm ergänzt man die VT100-Translations:

XTerm*VT100.translations: \
    :<KeyPress> KP_Add:string("+") \n\
    :<KeyPress> KP_Subtract:string("-") \n\
    :<KeyPress> KP_Multiply:string("*") \n\
    :<KeyPress> KP_Divide:string("/") \n\
    :<KeyPress> KP_Decimal:string(".") \n\
    :<KeyPress> KP_Separator:string(",") \n\
    :<KeyPress> KP_1:string("1") \n\
    :<KeyPress> KP_2:string("2") \n\
    :<KeyPress> KP_3:string("3") \n\
    :<KeyPress> KP_4:string("4") \n\
    :<KeyPress> KP_5:string("5") \n\
    :<KeyPress> KP_6:string("6") \n\
    :<KeyPress> KP_7:string("7") \n\
    :<KeyPress> KP_8:string("8") \n\
    :<KeyPress> KP_9:string("9") \n\
    :<KeyPress> KP_0:string("0") \n\
    …

wobei … der bisherige Inhalt der VT100-Translations ist; siehe die xterm man page (und zum Syntax Anhang B von «X Toolkit Intrinsics - C Language Interface»).

[mail@…]

Ich konnte zumindest die Lösung für urxvt sowohl für den normalen Ziffernblock als auch für den auf der 4. Ebene verifizieren. Danke erstmal dafür.

[stephan]

Das Problem scheint ein programmspezifisches zu sein, auf das Neo keinen Einfluss hat.