Terminal: [Terminal] VT-Maus-Unterstützung

Erstellt am 8. Mai 2019  ·  38Kommentare  ·  Quelle: microsoft/terminal

  • Ihre Windows-Buildnummer: (Geben Sie ver an einer Windows-Eingabeaufforderung ein)

10.0.18890.1000

  • Was Sie tun und was passiert: (Kopieren und fügen Sie bestimmte Befehle und ihre Ausgabe ein oder fügen Sie Screenshots hinzu)

Ich verwende routinemäßig den Mausmodus in tmux mit WSL für die Fensterauswahl, die Größenänderung von Fenstern und das Scrollback, aktiviert in tmux.conf also:

  # -- mouse support ---------------------------------------------------------                                                                                                                                                                                        
  # Enable mouse control (clickable windows, panes, resizable panes)                                                                
  set -g mouse on

Während dies in conhost perfekt funktioniert, funktioniert es in Terminal überhaupt nicht; nichts passiert, als ob die Mausereignisse nie tmux erreichen würden.

  • Was ist falsch / was sollte stattdessen passieren:

Die tmux-Mausunterstützung (und vermutlich andere mausunterstützende Anwendungen) sollte wie in conhost funktionieren.

Area-Input Area-VT Issue-Feature Product-Terminal Resolution-Fix-Committed

Hilfreichster Kommentar

Ich warte gespannt darauf, dass dies in einer zukünftigen Version angezeigt wird - ich klicke weiter auf tmux-Fenster in der Hoffnung, dass die Maus funktioniert :)

Alle 38 Kommentare

Ja, das ist im Moment ein bekanntes Problem. Wir müssen an zwei Stellen Unterstützung für Maus hinzufügen: sowohl im Terminal, um Maussequenzen synthetisieren zu können, als auch, um Maussequenzen lesen zu können.

Dieses Problem verfolgt das erste Bit, die Terminal-Funktionalität.

Für das zweite Bit, den leeren Teil, siehe #376.

Leider funktioniert dies nicht, da die Mausereignisse mit TMUX die Notwendigkeit mehrerer Fenster aufschieben würden.
Ich hoffe, dass diese Funktion vor den Fenstern implementiert wird, dringend benötigt wird und die meisten Probleme lösen wird

Ich möchte darauf hinweisen, dass die Mausunterstützung auch in tmux innerhalb von Docker (über Powershell) nicht unterstützt wird. Ich weiß, dass dies daran liegt, dass die Funktionalität in Terminal einfach nicht vorhanden ist, daher funktioniert sie natürlich nicht in WSL oder Docker, aber ich dachte, ich erwähne es weiter.

die Maus funktioniert mit TMUX in WSL

Maus funktioniert mit wsltty: https://github.com/mintty/wsltty

@guibirow Vielleicht ist es dann ein Problem mit Docker im Terminal.

Nein. Bei Docker ist das kein Problem. Es ist ein Problem mit conpty (diesem Repo). Versuchen Sie wsltty, wenn Sie Mausunterstützung wünschen.

Gibt es Pläne, in Zukunft die vollständige Mausunterstützung in tmux für Docker über das Terminal zu aktivieren?

Ich kenne Docker nicht speziell, aber ich sehe nicht, warum es sich von einem normalen Terminal unterscheiden sollte. In dieser Ausgabe geht es darum, also pass auf!

Also habe ich gerade tmux durch WSL 1 im Terminal überprüft und die Maus wird dort auch nicht unterstützt. Ich vermute also, dass tmux selbst zu diesem Zeitpunkt im Terminal einfach nicht funktioniert und dass es sich nicht um ein Docker-Problem handelt. Ich bin mir nicht sicher, was

Sie müssen einen Befehl ausführen, um ihn zu aktivieren, ist standardmäßig nicht aktiviert.
Ich habe es gerade nicht, aber es ist so einfach set mouse on
Ich muss nächste Woche bestätigen, wenn ich meinen Laptop bekomme

Es funktioniert jedoch nur auf dem WSL-Terminal, nicht im neuen Windows-Terminal

Oh, ich hab's. Ja, es funktioniert gut im einfachen WSL-Fenster. Es funktioniert nur nicht, wenn es in das neue Windows-Terminal eingebettet ist.

Wenn Sie Mausunterstützung implementieren, stellen Sie bitte sicher, dass Sie auch die SGR (1006)-Erweiterung implementieren.

Das herkömmliche, bytebasierte Protokoll lässt nur Zeilen- und Spaltennummern bis 223 zu, da 32 zu dieser Nummer hinzugefügt wird und diese als einzelnes Byte gesendet wird. Es ist nicht ungewöhnlich, dass die Spaltengrenze zu klein ist. (Übrigens sind die generierten Daten ab Spalte 95 nicht 7-Bit-sauber und kein gültiges UTF-8, was ein Problem für die Codierung von Konversionsschichten wie luit darstellt.)

Die SGR 1006-Erweiterung behebt diese Probleme, indem die Zahlen als Dezimalziffern kodiert werden und wird von vielen Anwendungen unterstützt.

Wenn diese Erweiterung nicht angefordert wird, generieren Sie bitte kein Ereignis, wenn die Zeile oder Spalte 223 überschreitet. Andernfalls könnte ein Überlauf unangenehme Folgen haben. Zum Beispiel könnte das Klicken auf Spalte 227 das Byte 32+227 = 259 = 3 = Strg+C erzeugen, das typischerweise das Unterbrechungszeichen ist, das ein SIGINT an den laufenden Prozess sendet.

So! Conhost unterstützt tatsächlich DECSET 1006 ! Da wir diese Zwischenschicht haben (die Pseudokonsole, die mit dem Conhost kommunizieren muss), können wir auswählen, welche Art von Mausmodus die Pseudokonsole anfordert und unterstützt. Ich sehe keinen Grund, warum das nicht einfach 1006 :smile: Danke für die Info!

Zur Verdeutlichung, da wir einen Conhost in der Mitte haben, würde das so aussehen:

                                      |                 |
                 DECSET 1002, 1005    | Windows conhost |
+-------------+                       |  (in PTY mode)  |
|             +----------------------->                 |
| Application |                       |                 |
|             <-----------------------+                 |
+-------------+                       |                 |
                 mouse information    |                 |
                 1002 in 1005 format  |                 |
                                      |                 |
                                      +---+---------^---+
                                          |         |
                                          |         | mouse information in
                         DECSET 1002,1006 |         | SGR Extended Format
                                          |         | (1002+1006)
                                          |         |
                                      +---v---------+---+
                                      |                 |
                                      | Windows         |
                                      |  Terminal       |
                                      |                 |
                                      |                 |
                                      |                 |
                                      |                 |
                                      +-----------------+

Meinten Sie 1005 zwischen der Anwendung und dem Conhost, oder ist das ein Tippfehler in diesem Bild? Es gibt auch die Mauserweiterungen 1005 und 1015, die jedoch aufgrund ihrer Mängel kaum (wenn überhaupt) verwendet werden, was Anwendungen nicht interessiert.

1005 (xterms Zwei-Byte-UTF-8), 1015 (urxvt) und 1006 (xterm SGR) in dieser chronologischen Reihenfolge sind drei sich gegenseitig ausschließende Erweiterungen, um die Beschränkung der Spaltennummer zu beheben. Siehe zB Midnight Commander Ausgaben 2662 und 2956 für eine technische Beschreibung der Fehler der ersten beiden. Beachten Sie, dass diese Geschichte jetzt 6-8 Jahre alt ist. Mir ist keine Anwendung bekannt, die das problematische 1005 und/oder 1015 unterstützt, aber nicht das okay 1006. Daher sehe ich keinen Sinn darin, Unterstützung für die ersten beiden zu implementieren (obwohl es sehr einfach sein sollte, sie zu implementieren ).

Das könnte sehr gut ein Tippfehler sein, im Moment unterstützt conhost tatsächlich eine Reihe verschiedener Mausmodi, einschließlich, aber nicht beschränkt auf 1005 und 1006.

Es ist kein Tippfehler. Entschuldigung, dies sollte veranschaulichen, wie das Pseudokonsolensystem eine Reihe von Mausmodi auf der Clientseite unterstützen kann (eine Anwendung fordert 1005, 1015, Legacy-VT220 usw. an), aber der pty-Pipe eine einheitliche Mausmodusschnittstelle (1006) präsentieren kann Halter.

Dieses Diagramm passt zugegebenermaßen besser in #376, das der infrastrukturelle Teil dieses Fehlers ist.

@DHowett-MSFT Super, danke für die Klarstellung!

Ich warte gespannt darauf, dass dies in einer zukünftigen Version angezeigt wird - ich klicke weiter auf tmux-Fenster in der Hoffnung, dass die Maus funktioniert :)

Gibt es diesbezüglich Fortschritte?

@sandric Nicht besonders - wenn es etwas

@carlos-zamora beginnt diesen Monat mit dieser Arbeit (wie Sie an den Feldern "Zugewiesen an" und "Meilenstein" rechts sehen können). Er hat einen PR (#3963) heraus, der mit der Arbeit für #376 beginnt, eine der Voraussetzungen für dieses Feature.

@zadjii-msft Die von Ihnen verlinkte PR sagt, dass sie zusammengeführt wurde Ist das jetzt richtig?

Basierend auf dem Kommentar in den Versionshinweisen:

Die Pseudokonsole verarbeitet nun Maus-Escapes, bringt aber noch nicht viel damit (#3963)

Es scheint (noch) nicht. Ich bleib dran!

@fpqc ja, das ist richtig, dass ein PR zusammengeführt wurde. Nach dieser Diskussion ist noch eine Menge Arbeit erforderlich, bevor dies im Terminal vollständig funktioniert:

  • [ ] Conpty gibt beim Aufrufen eines Mausmodus eine [Sequenz] aus, um den Terminals mitzuteilen, dass sie VT-Mausmodus-Eingaben als SGR-Sequenzen synthetisieren sollen (mit Schweben, Scrollen usw.).
  • [ ] Conhost übersetzt Mauseingaben in VT sowohl von conpty als auch vom HWND auf die gleiche Weise
  • [ ] Terminal kann [Sequenz] verbrauchen, um Eingaben im VT-Mausmodus zu synthetisieren

Und dann natürlich dieses Thema:

  • [ ] Terminal synthetisiert Mauseingabesequenzen

Wie kopieren wir den Text, wenn VT Mouse aktiviert ist? Ich konnte es nicht auf Vim oder Tmux tun.

Halten Sie die Umschalttaste gedrückt, um mit dem Terminal selbst anstatt mit der darin enthaltenen Anwendung zu interagieren.

Das ist so toll! Wann werden wir eine Vorschau davon im Store sehen?

Bleiben Sie dran

Aus dem Shop heruntergeladen! Die Maus funktioniert hervorragend in VIM, htop und Tmux. Endlich ist es an der Zeit, von allen anderen WSL-Terminals auf das Microsoft-Terminal umzusteigen! Gute Arbeit Jungs und vielen Dank!

PS: Schicht funktioniert auch super!

Ich bin gerade hierher gekommen, um @yveslange gelesen und dann die App aktualisiert ... und jetzt funktioniert die Maus perfekt.

Danke Leute!

@DHowett-MSFT: Maus funktioniert bei mir immer noch nicht mit Micro (https://github.com/zyedidia/micro), während sowohl Maus als auch Scrollrad im Standard-Powershell- oder cmd.exe-Terminal einwandfrei funktionieren. Funktioniert die Mausunterstützung derzeit nur in WSL?

@nicolus tatsächlich funktioniert die

@zadjii-msft
Mausereignisse funktionieren bei mir nicht mit einem benutzerdefinierten Profil mit "commandline": "ssh [...]" . Wird dies auch erwartet, bis #376 gelöst ist? Gibt es einen guten Workaround?

Bearbeiten : Oder ist das nur ein Ergebnis von PowerShell / Win32-OpenSSH # 1310 und würde sonst funktionieren?

Dies ist ein Ergebnis von https://github.com/PowerShell/Win32-OpenSSH/issues/1310 , das (zum Glück) in der 8.x-Serie behoben wurde.

@DHowett-MSFT Danke für die schnelle Antwort. Gibt es in diesem Fall eine vernünftige Möglichkeit, jetzt manuell auf eine Version mit dem Fix zu aktualisieren, oder ist es besser, einfach zu warten?

Sicher, lade einfach die neueste Version von ihrer Releases-Seite herunter!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen