Einige X-Apps akzeptieren meine nicht-lateinischen Zeichen, andere ignorieren sie

502
einpoklum

Ich bin mit einer X - Umgebung mit einem Dual - Tastaturlayout: us,il. In einigen meiner Anwendungen und im ilLayout werden hebräische Zeichen nicht registriert, Satzzeichen dagegen. In anderen Apps registrieren sich die hebräischen Zeichen gut und werden zu dem Text hinzugefügt, den ich tippe. Das englische Layout funktioniert gut. Ich werde im Folgenden alle Details zu meiner Konfiguration angeben.

Meine Fragen sind: Warum passiert das? Und was noch wichtiger ist, wie kann ich das beheben / umgehen und alle Apps auch hebräische Zeichen zulassen?

Details zu meinem Setup

  • Physisches Tastaturlayout: Standard US 104-Taste (wie diese ).
  • 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: Dies passiert mir sowohl bei Cinnamon als auch bei LXQt. habe noch keine anderen ausprobiert

  • Apps, die hebräische Zeichen ablehnen: Cinnamon's 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 aauf die 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 Wechseln 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 aerneuten Drücken 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

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 erstellen, wird der Benutzer nicht dieses Problem auftritt. Es muss also eine benutzerspezifische Einstellung sein.
  • Wenn ich hebräischen Text kopiere, kann ich ihn in die Apps einfügen, die hebräische Zeichen ablehnen.
  • Ich habe meinen Heimatordner von einer früheren, nicht von Devuan stammenden Linux-Installation beibehalten (es war Linux Mint 18.3).
2
Versuchen Sie diese kleine Änderung: `setxkbmap -option grp: switch, grp: alt_shift_toggle, grp_led: scroll us, il`. harrymc vor 5 Jahren 0
@ harrymc: 1. Das funktioniert nicht. 2. Dies scheint xkb-Optionen hinzuzufügen (anstatt sie zu ersetzen) (mit `setxkbmap -query` überprüft). einpoklum vor 5 Jahren 0
Ich kenne dein Linux nicht. Könnten Sie bitte einige weitere Informationen zu Ihrem Tastaturlayout hinzufügen? Wie geben Sie diese Zeichen ein? Was ist deine Tastatur? Welche Schriftarten? harrymc vor 5 Jahren 0
@ harrymc: Physisches Tastaturlayout: Hinzugefügt. "Wie geben Sie diese Zeichen ein?" Ich drücke Tasten auf meiner Tastatur. "Welche Schriftarten?" Für alle ist es egal. einpoklum vor 5 Jahren 0
Die Frage ist also nicht "Zeichen akzeptieren" (sie kopieren und einfügen), sondern "Tastendruck akzeptieren". Der erste Schritt ist "xev" auszuführen und herauszufinden, welche Keysyms / Keycodes die hebräischen Zeichen enthalten (bitte Frage bearbeiten). In Ihrer App-Liste funktionieren KDE- und Gnome-Apps, während ältere Apps wie xterm dies nicht tun. Die Vermutung ist also, dass diese Apps die Keysymptome einfach nicht verarbeiten. Haben Sie statt xterm urxvt ausprobiert? dirkt vor 5 Jahren 0
@dirkt: Der letzte Teil deines Kommentars ist falsch - Gnome-Apps funktionieren nicht. einpoklum vor 5 Jahren 0
@dirkt: Die xev-Ausgabe wurde hinzugefügt. Es scheint, als würde X die hebräischen Zeichen gut sehen ... vielleicht ist es eine gtk / Gnome-Sache? einpoklum vor 5 Jahren 0

3 Antworten auf die Frage

1
harrymc

Die Antwort unten hat das Problem des Posters nicht gelöst, aber die anschließende Diskussion deutete schließlich darauf hin.

Wir kamen beide zu dem Schluss, dass die Ursache des Problems ein Unterschied zwischen Mint und Devuan war, der sich manifestierte, als das Plakat seinen gesamten Heimatordner von einem zum anderen kopierte. Ein großer Hinweis war die Tatsache, dass sich das Problem unter dem Profil des Root-Benutzers nicht manifestierte.

Das Poster untersuchte dann die Dateien in seinem Heimatordner, die sich auf die Tastatur beziehen, und das Ergebnis ist in seiner Antwort zu finden.


Ihr Problem scheint das gleiche wie in der Post zu sein. Das
Terminal akzeptiert keine eingegebenen Unicode-Zeichen .

Die in diesem Beitrag gefundene .XmodmapProblemumgehung bestand darin, die Schlüsselnamen durch ihre Unicode-Hex-Codes zu ändern und zu ersetzen.

In dem obigen Beitrag für das griechische ifonlyifZeichen ersetzte das Plakat die Zeile:

Schlüsselcode 58 = M M M M Prozent Greek_mu KP_1 KP_1 ifonlyif

von der Linie:

Schlüsselcode 58 = M M M M Prozent Greek_mu KP_1 KP_1 U21D4

hebrew_shinWenn Sie nicht über Ihre Umgebung verfügen, sollten Sie in Ihrem Beispiel für den Schlüsselcode 38 den Text durch U05E9 (oder ähnliches) ersetzen .

Wenn dies für Sie funktioniert, müssen Sie dasselbe für alle hebräischen Buchstaben tun, was leider ziemlich schmerzhaft sein wird. Wenn Sie Glück haben, wird der Unicode-Hex-Code möglicherweise bereits in Xmodmap erwähnt, sodass Sie dies mit etwas sedMagie tun können .

Natürlich sollte ich keine benutzerspezifischen Änderungen vornehmen oder manuell etwas ändern müssen. Was ich brauche, sind die relevanten Dateien, die in anderen Distributionen (z. B. Ubuntu, Mint, Fedora) dazu führen, dass alle Apps die entsprechenden Zeichen akzeptieren. Aber +1 für deine bisherige Hilfe. einpoklum vor 5 Jahren 0
Dieser Vorschlag scheint auch nicht anwendbar zu sein, da `xmodmap -pke | grep shin` gibt mir `keycode 38 = a A hebrew_shin A U05B0` bereits. einpoklum vor 5 Jahren 0
Seltsam: [U05B0] (https://codepoints.net/U+05B0?lang=de) scheint falsch zu sein. Shin sollte [U05E9] sein (http://www.fileformat.info/info/unicode/char/05e9/index.htm). U05B0 ist ein Vokalzeichen und hat keine eigene Anzeige. Ich frage mich, ob dies Ihr Problem ist, dass die hebräische Xmodmap-Tabelle in Ihrer Distribution für dieses Tastaturlayout durcheinander geraten ist. harrymc vor 5 Jahren 0
Ich versuche, die relevanten Dateien zu finden (`/ usr / share / xkb`?) Und sie mit einer anderen Distribution zu vergleichen. einpoklum vor 5 Jahren 0
`Symbole / il` ist also für beide Distros gleich. U05B0 ist jedoch kein Vokalzeichen, es ist der shva-Zeichenmodifikator - den Sie anscheinend in die dritte Ebene bekommen sollten. Die entsprechende Symboldateizeile lautet: `Schlüssel{[hebrew_shin, A, U05B0]}; // Shva`. Nun, Sie könnten mir sagen "tauschen Sie das" hebrew_shin "für" U05E9 "- aber das ist nicht der" richtige Weg ", weil dies auf Lubuntu nicht so getauscht wird. Das Problem ist anderswo, es ist eine Art Interpretationsproblem. einpoklum vor 5 Jahren 1
Ich wurde frustriert, also habe ich Devuan in einer VM installiert und habe kein Problem damit, Alt-Shift zu tippen und zu wechseln. Hier ist [Beweis] (https://i.stack.imgur.com/JGdpe.jpg). Ich habe den Befehl `setxkbmap -option grp: switch, grp: alt_shift_toggle, grp_led: scroll us, il` verwendet. Was auch immer die anderen Manipulationen waren, die nicht geholfen haben und die rückgängig gemacht werden sollten. harrymc vor 5 Jahren 0
Hinweis: Ich habe Devuan Ascii verwendet. harrymc vor 5 Jahren 0
1. Sie haben ein Terminal verwendet. Ich hatte kein Problem mit der Eingabe von Terminals. 2. Ich habe meinen Heimatordner aus einer früheren Distribution verwendet (Linux Mint 18.3). Ich kann das nicht ganz rückgängig machen - es sei denn, ich weiß, was zu tun ist. Ich kann jedoch bestätigen, dass sich das Problem mit dem Profil des Root-Benutzers nicht manifestiert. einpoklum vor 5 Jahren 0
Ich denke, wir können daraus schließen, dass die Ursache ein Unterschied zwischen Mint und Devuan ist, der sich beim Kopieren Ihres Home-Ordners manifestierte. Möglicherweise handelt es sich um eine Datei, die sich auf xmodmap in Ihrem Home-Ordner bezieht. harrymc vor 5 Jahren 0
Einige Möglichkeiten: `~ / .Xmodmap`,` ~ / .xinitrc`, `~ / .config / autostart / xmodmap.desktop`,` ~ / .bashrc` oder `/ etc / bash.bashrc`. Folgendes kann beim Debuggen helfen: sudo cat / var / log / syslog | grep -B 5 -A 5 xmodmap`. harrymc vor 5 Jahren 0
Nichts davon, aber Sie haben mich dazu inspiriert, die Lösung zu finden. Sehen Sie meine neue Antwort. einpoklum vor 5 Jahren 0
1
einpoklum

Sie müssen Ihre ~ / .xinputrc-Datei entfernen / löschen.

Inspiriert von einigen Ratschlägen, die von @harrymc vorgeschlagen wurden, habe ich den Täter gefunden: meine ~/.xinputrcDatei, die auf meiner vorherigen Distribution (Linux Mint 18.3) generiert wurde. Es sagt:

# im-config(8) generated on Wed, 25 Jan 2017 22:44:55 +0100 run_im xim # im-config signature: 21f3e409b30c3de81e8302273ccb3d5c - 

Der im-configMechanismus ist

die Eingabemethode für X Window System mit GTK-GUI oder Konsolenterminal-Dialog.

Das erklärt, warum nur (einfachere) GTK-Apps betroffen zu sein scheinen. Ich bin mit dem Geschäft mit Eingabemethoden überhaupt nicht vertraut, aber - wenn ich diese Datei entferne oder die run_imOption auskommentiere - scheinen alle Apps jetzt die hebräischen Zeichen zu akzeptieren, die ich eingebe.

0
dirkt

Teilantwort:

Wenn Sie aund vergleichen ש, werden Sie sehen

XLookupString gives 1 bytes: (61) "a" 

vs

XLookupString gives 0 bytes: 

Und das ist das Problem, weil XLookupString auf der Manpage nur Latin-1 behandelt, so dass Anwendungen, die sich auf XLookupString verlassen, um die Tastendrücke in Zeichen zu übersetzen, ein leeres Ergebnis erhalten Marken tun. "

Und anscheinend umgehen einige andere Anwendungen, zB die KDE-Anwendungen, dies oder verwenden eine andere Methode.

Ich weiß nicht, wie ich das reparieren soll. Sie müssen Anwendungen verwenden, die Unicode / UTF-8 verstehen, und außerdem die empfangenen Tastensätze ordnungsgemäß übersetzen. Das Patchen des Quellcodes von nicht funktionierenden Apps ist eine Option, aber wenn es einfach wäre, bin ich mir sicher, dass jemand dies bereits getan hätte ... also würde ich davon ausgehen, dass es ein paar Probleme gibt.

Es gibt Alternativen zu XLookupStringdieser Arbeit mit UTF-8 ( Xutf8LookupString ).

Das funktioniert aber auch mit anderen Distributionen ... und ich verwende Apps, die Unicode verstehen. einpoklum vor 5 Jahren 0
Wenn ich "xev" in Lubuntu 18.04 versuche, heißt es, "XLookupString gibt 2 Bytes: (d7 a9)" ש "`. einpoklum vor 5 Jahren 0
Interessant. Es sieht also so aus, als gäbe es zwei Implementierungen: Eine, die der Manpage folgt und sagt, sie sollte nur Latin-1 ausführen, eine, die das ignoriert und utf-8 trotzdem gibt. Dies bedeutet, dass es sich bei dem Schuldigen entweder um verschiedene X-Bibliotheken oder um verschiedene Xkbd-Dateien handelt, die dazu führen, dass XLookupString anders wirkt. Der nächste Schritt sollte also den Quellcode von XLookupString von Devuan verwenden. dirkt vor 5 Jahren 1
Vielleicht wird es nur mit den falschen Flags oder so kompiliert? einpoklum vor 5 Jahren 0
Keine Ahnung. Das X-Build-System ist (oder war das letzte Mal, als ich es angesehen habe) ziemlich komplex. Ich würde die Pakete sowohl für Lubuntu als auch für Devuan aus dem Quellcode zusammenstellen und genau prüfen, was passiert, wenn es mein Problem wäre, aber das kann ziemlich viel Zeit in Anspruch nehmen. dirkt vor 5 Jahren 0