Ich verwende eine X-Umgebung mit einem doppelten Tastaturlayout: us,il
. Nun, in einigen meiner Anwendungen und in der il
Layout, hebräische Zeichen werden nicht registriert, Satzzeichen jedoch. In anderen Apps lassen sich hebräische Zeichen gut registrieren und werden zu dem Text hinzugefügt, den ich schreibe. Das englische Layout funktioniert gut. Ich werde im Folgenden alle Details zu meiner Konfiguration bereitstellen.
Meine Fragen sind: Warum passiert das? Und was noch wichtiger ist, wie kann ich dies beheben / umgehen und dafür sorgen, dass alle Apps auch hebräische Zeichen akzeptieren?
Details zu meinem Setup
- Physisches Tastaturlayout: Standard US 104-Taste (wie dieses ).
- Betriebssystemverteilung: Devuan 2.0 ASCII (~ = Debian 9.0 Stretch)
XKB-Konfiguration:
$ setxkbmap -query rules: evdev model: pc105 layout: us,il variant: , options: grp:alt_shift_toggle,grp_led:scroll
Desktop-Umgebung: Das passiert mir mit Cinnamon und LXQt; habe andere noch nicht ausprobiert.
- Apps, die hebräische Zeichen ablehnen: Cinnamons Alt + F2-Startprogramm; LeafPad; GEdit, xterm.
- Apps, die hebräische Zeichen akzeptieren: KWrite, GNOME Terminal, LibreOffice, Firefox, Kolourpaint, lxterminal, Konsole.
xev
Ausgabe
Ausgabe beim Drücken von a
auf der Tastatur:
KeyRelease event, serial 34, synthetic NO, window 0x7e00001,
root 0x43, subw 0x0, time 369470632, (96,-25), root:(146,62),
state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False
KeyPress event, serial 34, synthetic NO, window 0x7e00001,
root 0x43, subw 0x0, time 369474392, (96,-25), root:(146,62),
state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False
Ausgabe beim Umschalten des Tastaturlayouts:
KeyPress event, serial 34, synthetic NO, window 0x7e00001,
root 0x43, subw 0x0, time 369547896, (75,-23), root:(125,64),
state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 34, synthetic NO, window 0x7e00001,
root 0x43, subw 0x0, time 369548008, (75,-23), root:(125,64),
state 0x8, keycode 62 (keysym 0xfe08, ISO_Next_Group), same_screen YES,
XKeysymToKeycode returns keycode: 50
XLookupString gives 0 bytes:
XFilterEvent returns: False
PropertyNotify event, serial 34, synthetic NO, window 0x7e00001,
atom 0x176 (XKLAVIER_STATE), time 369548013, state PropertyNewValue
PropertyNotify event, serial 34, synthetic NO, window 0x7e00001,
atom 0x176 (XKLAVIER_STATE), time 369548013, state PropertyNewValue
KeyRelease event, serial 34, synthetic NO, window 0x7e00001,
root 0x43, subw 0x0, time 369548072, (75,-23), root:(125,64),
state 0x2008, keycode 62 (keysym 0xfe08, ISO_Next_Group), same_screen YES,
XKeysymToKeycode returns keycode: 50
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 34, synthetic NO, window 0x7e00001,
root 0x43, subw 0x0, time 369548168, (75,-23), root:(125,64),
state 0x2008, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Ausgabe beim Drücken von a
nochmal auf der Tastatur (diese Taste entspricht auch dem hebräischen Buchstaben shin, ש):
KeyPress event, serial 34, synthetic NO, window 0x7e00001,
root 0x43, subw 0x0, time 369560440, (75,-23), root:(125,64),
state 0x2000, keycode 38 (keysym 0xcf9, hebrew_shin), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 34, synthetic NO, window 0x7e00001,
root 0x43, subw 0x0, time 369560504, (75,-23), root:(125,64),
state 0x2000, keycode 38 (keysym 0xcf9, hebrew_shin), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
xmodmap -pke
Ausgabe
Ein Teil der Ausgabe von xmodmap -pke
:
... etc. etc. ...
keycode 24 = q Q slash Q U05C2
keycode 25 = w W apostrophe W U05C1
keycode 26 = e E hebrew_qoph E U05B8
keycode 27 = r R hebrew_resh R U05B3
keycode 28 = t T hebrew_aleph T
keycode 29 = y Y hebrew_tet Y U05F0
keycode 30 = u U hebrew_waw U U05B9
keycode 31 = i I hebrew_finalnun I
keycode 32 = o O hebrew_finalmem O
keycode 33 = p P hebrew_pe P U05B7
keycode 34 = bracketleft braceleft bracketright braceright U05B2
keycode 35 = bracketright braceright bracketleft braceleft U05BF
keycode 36 = Return NoSymbol Return
keycode 37 = Control_L NoSymbol Control_L
keycode 38 = a A hebrew_shin A U05B0
keycode 39 = s S hebrew_dalet S U05BC
keycode 40 = d D hebrew_gimel D
keycode 41 = f F hebrew_kaph F
keycode 42 = g G hebrew_ayin G U05F1
keycode 43 = h H hebrew_yod H U05F2
keycode 44 = j J hebrew_chet J U05B4
keycode 45 = k K hebrew_lamed K
keycode 46 = l L hebrew_finalkaph L rightdoublequotemark
keycode 47 = semicolon colon hebrew_finalpe colon doublelowquotemark
keycode 48 = apostrophe quotedbl comma quotedbl U05F4
keycode 49 = grave asciitilde semicolon asciitilde U05F3
keycode 50 = Shift_L ISO_Next_Group Shift_L ISO_Next_Group
keycode 51 = backslash bar backslash bar U05BB
keycode 52 = z Z hebrew_zain Z
keycode 53 = x X hebrew_samech X U05B6
keycode 54 = c C hebrew_bet C U05B1
keycode 55 = v V hebrew_he V
keycode 56 = b B hebrew_nun B NoSymbol U05C6
keycode 57 = n N hebrew_mem N
keycode 58 = m M hebrew_zade M U05B5
keycode 59 = comma less hebrew_taw greater rightsinglequotemark
keycode 60 = period greater hebrew_finalzade less singlelowquotemark
keycode 61 = slash question period question division
... etc. etc. ...
Sprachbezogene Umgebungsvariablen
$ env | grep LANG
LANG=en_IL
GDM_LANG=en_US.utf8
LANGUAGE=en_IL:en
Weitere Hinweise
- Wenn ich ein sauberes Benutzerkonto erstelle, tut dies dieser Benutzer nicht tritt dieses Problem auf. Es muss also eine Art benutzerspezifische Einstellung sein.
- Wenn ich hebräischen Text kopiere, kann ich ihn in die Apps einfügen, die hebräische Zeichen ablehnen, und er wird in Ordnung angezeigt.
- Ich habe meinen Home-Ordner von einer früheren, nicht devuanischen Linux-Installation (es war Linux Mint 18.3) behalten.
setxkbmap -option grp:switch,grp:alt_shift_toggle,grp_led:scroll us,il
.setxkbmap -query
).xev
und finde heraus, wie die Keysyms / Keycodes der hebräischen Zeichen aussehen (bitte Frage bearbeiten). In Ihrer App-Liste funktionieren KDE- und Gnome-Apps, ältere Apps wie xterm dagegen nicht. Die Vermutung ist also, dass diese Apps die Keysyms einfach nicht verarbeiten. Haben Sie versucht, urxvt anstelle von xterm?Antworten:
Sie müssen Ihre ~ / .xinputrc-Datei entfernen / löschen.
Inspiriert von einer von @harrymc vorgeschlagenen Vermutung, habe ich den Schuldigen gefunden: my
~/.xinputrc
Datei, die mit meiner vorherigen Distribution erstellt wurde (Linux Mint 18.3). Es sagt:Das
im-config
Mechanismus istDas erklärt, warum nur (einfachere) GTK-Apps betroffen zu sein scheinen. Ich kenne mich mit Eingabemethoden überhaupt nicht aus, aber - wenn ich diese Datei entferne oder auskommentiere
run_im
Option - Alle Apps scheinen nun die von mir eingegebenen hebräischen Zeichen zu akzeptieren.quelle
Die Antwort unten löste nicht das Problem des Posters, sondern die Diskussion darüber gefolgt hat endlich darauf hingewiesen.
Wir kamen beide zu dem Schluss, dass die Ursache des Problems ein Unterschied zwischen war Mint und Devuan, die sich manifestierten, als das Plakat sein gesamtes kopierte Home-Ordner von einem zum anderen. Ein großer Hinweis war die Tatsache, dass unter dem Profil des Root-Benutzers, Das Problem hat sich nicht manifestiert.
Das Poster überprüfte dann die Dateien in seinem Home - Ordner im Zusammenhang mit der Tastatur, und das Ergebnis ist in seiner Antwort zu finden.
Dein Problem scheint das gleiche zu sein wie in der Post
Das Terminal akzeptiert einige eingegebene Unicode-Zeichen nicht .
Die in diesem Beitrag gefundene Problemumgehung bestand darin, Änderungen vorzunehmen
.Xmodmap
und ersetzen Sie die Keysymnames durch ihre Unicode-Hex-Codes.Im obigen Beitrag für den Griechen
ifonlyif
Zeichen ersetzt das Plakat die Zeile:durch die Linie:
Da Sie nicht über Ihre Umgebung verfügen, sollten Sie in Ihrem Beispiel den Schlüsselcode 38 verwenden Ersetzen Sie den Text
hebrew_shin
von U05E9 (oder etwas ähnlichem).Wenn dies für Sie funktioniert, müssten Sie das gleiche für alle hebräischen Buchstaben tun, das wird leider ziemlich schmerzhaft sein. Wenn Sie Glück haben, könnte der Unicode-Hex-Code bereits erwähnt sein in Xmodmap können Sie es also über einige tun
sed
Zauber.quelle
xmodmap -pke | grep shin
gibt mirkeycode 38 = a A hebrew_shin A U05B0
bereits./usr/share/xkb
vielleicht?) und vergleiche sie mit einer anderen Distribution.symbols/il
ist für beide Distributionen gleich. Jedoch,U05B0
ist kein Vokalzeichen, sondern der Shva-Zeichenmodifikator, den Sie anscheinend in der dritten Ebene erhalten sollen. Die relevante Symboldateizeile lautet:key <AC01> { [ hebrew_shin, A, U05B0 ] }; // Shva
. Nun könnten Sie mir sagen "Swap thehebrew_shin
zumU05E9
- aber das ist nicht der "richtige" Weg, weil es auf Lubuntu nicht so getauscht wird. Das Problem liegt woanders; Es ist eine Art Interpretationsproblem.Teilantwort:
Wenn Sie vergleichen
a
undש
, du wirst sehengegen
Und das ist das Problem, denn wenn man sich die Manpage ansieht, XLookupString Fasst nur Latin-1 an, sodass Anwendungen, die sich auf XLookupString verlassen, um die Tastendrücke in Zeichen zu übersetzen, ein leeres Ergebnis erhalten.
Und anscheinend einige andere Anwendungen, z. Die KDE-Versionen umgehen dies oder verwenden eine andere Methode.
Ich weiß nicht, wie ich das beheben soll. Sie müssen Anwendungen verwenden, die Unicode / UTF-8 verstehen und die empfangenen Keysyms ordnungsgemäß übersetzen. Das Patchen des Quellcodes von nicht funktionierenden Apps ist eine Option, aber wenn es einfach gewesen wäre, hätte das bestimmt schon jemand gemacht ... also würde ich davon ausgehen, dass es einige Fallstricke gibt.
Alternativen zu
XLookupString
die mit UTF-8 arbeiten ( Xutf8LookupString ) existieren.quelle
xev
am Lubuntu 18.04 heißt esXLookupString gives 2 bytes: (d7 a9) "ש"
.