alt-d alt-f usw. funktioniert in meinem xterm nicht mehr

8

Auf meinem Debian-System passiert manchmal etwas Seltsames. Normalerweise kann ich an der Eingabeaufforderungszeile eine Kombination wie Alt-D verwenden, um ein Wort zu löschen, Alt-F, um zum nächsten Wort zu gelangen usw.

Aber ziemlich regelmäßig passiert etwas in meinem xterm, was dazu führt, dass alt-d und alt-f nicht mehr funktionieren: Plötzlich drucken sie 'ä' (alt-d) und 'æ' (alt-f).

Beachten Sie, dass dies in einem Terminal geschieht, das sich so verhält, wie ich es zuerst wollte. Aber dann muss irgendwie ein Code oder etwas gesendet werden, das das Verhalten des Terminals ändert.

Es passiert in xterm, weil ich dort immer arbeite. Wenn ich mit Strg + Alt + F1 zu einer Konsole gehe, macht Alt-D standardmäßig das, was ich will (Wort löschen), und Alt-F auch. Vielleicht könnte ich das auch durch schlechte Manipulationen vermasseln: Ich weiß es einfach nicht, weil ich nicht im Textmodus arbeite.

Beachten Sie auch, dass, wenn ich ein xterm aus dem "kaputten" xterm spawne, das neue xterm wie erwartet funktioniert.

Was ist los? Was schalte ich ein, das vorher ausgeschaltet war?

Meine .Xresources sagen, dass und wieder einmal, wenn ich ein xterm öffne, es sich so verhält, wie ich es erwarte, ist es erst später, dass "etwas" dazu führt, dass es zu kaputten "I-print-Zeichen-mit-diakritischen Zeichen-und- anderer Unsinn " Modus:

$ more .Xresources 
XTerm.vt100.eightBitInput: false
XTerm*eightBitInput: False

linux xterm

— Weezy
quelle

11

du brauchst

xterm*metaSendsEscape:  true

in Ihren ~ / .Xdefaults

xrdb ~/.Xdefaults

Starten Sie ein neues xterm, hoffentlich sollte das das Problem nicht mehr haben

— Freidenker
quelle

@freethinkey: Wenn ich ein neues xterm starte, gibt es nie ein Problem: aber es macht mich verrückt, wenn mein aktuelles xterm es tut. Aber wie kommt es, dass es zuerst funktioniert, dann interpretiert jemand, den das xterm hat, ein Meta nicht mehr als Flucht, obwohl es 5 Sekunden vor demselben xterm als Flucht interpretiert wurde? (+1 übrigens)

— Weezy

Nun, Sie sind sich nicht sicher, was das Zurücksetzen der Einstellungen ist. Sie können Strg + Linksklick ausführen und sehen, ob "Meta Sends Escape" angekreuzt ist oder nicht, wenn es erneut passiert

— Freidenker

2

Hat für mich gearbeitet. xterm jetzt schwarz auf weiß statt weiß in schwarz wie vorher.

— SabreWolfy

1

füge das hinzu:

% grep -i escape .Xdefaults 
     xterm*metaSendsEscape: true

(Sagen Sie xterm also, dass Ihr altSchlüssel sendet escape)

— Akira
quelle

+1 auch, der gleiche Kommentar wie für Freidenker: Wie kommt es, dass es zuerst funktioniert, dann interpretiert jemand das xterm ein Meta nicht mehr als Flucht, obwohl es 5 Sekunden zuvor von demselben xterm als Flucht interpretiert wurde?

— Weezy

Nun, Sie können Dinge im laufenden Betrieb ändern , sei es zufällig oder was auch immer: Wenn alt nicht mehr funktioniert, überprüfen Sie Ihr xterm, indem Sie die linke Strg- Taste drücken und prüfen, ob die Option aktiviert ist (genau wie @freethinker sagte). Dann untersuchen Sie, ob Sie einige Tasten gedrückt haben, bevor die Änderung stattgefunden hat

— Akira

2

Deutsch sind wir? strg ? Sicherlich muss das Strg sein !? :)

— Weezy

Nun, Brainiac, in meinem Profil steht ganz klar "Deutschland", also ... trivial zu erkennen, auch ohne das, was auf der Tastatur gedruckt ist.

— Akira

0

Ich habe hier das gleiche Problem. Auf meinem lokalen xterm unter Debian funktioniert alles einwandfrei. Wenn ich jedoch in einen RHEL-Server ssh, funktioniert mb / mf nicht. Sie funktionieren immer noch nicht, selbst nachdem ich mich von RHEL abgemeldet habe.

Ich habe den Quellcode ausgegraben und einen Hack gefunden. Fügen Sie einfach die folgenden Zeilen in Ihre ~ / .Xresources ein:

XTerm*VT100*Translations: #override \n\
     Meta <KeyPress>:insert-seven-bit()

— zhao tianlei
quelle