Die Registerkarten wurden ursprünglich in Betracht gezogen, aber vom Team weit verbreitet, da dies zu Verwirrung führen kann, wenn die Registerkarten unten angezeigt werden und sich vscode weniger "leicht" anfühlt. Wenn ich keine Tastenkombinationen für die Terminals focusNext und focusPrevious hätte, wäre ich sehr frustriert über das Fehlen von Registerkarten, da Dropdowns eine schwierige Aufgabe sind.

Auch die geteilte Ansicht wurde berücksichtigt und dann priorisiert, da Anwendungen wie tmux im integrierten Terminal ausgeführt werden können, um ein ähnliches Ergebnis zu erzielen. Ich habe mich seitdem davon entfernt und möchte das Terminal wirklich teilen können. Ich möchte nicht besonders die Tastenkombinationen von tmux Teil meines Workflows besteht darin, dass mehrere Terminals gleichzeitig angezeigt werden. Normalerweise ein Überwachungsbefehl, den ich auf Fehler überwache, und ein manueller Erstellungs- oder Startbefehl. Verfolgen wir die Aufteilung des Terminals in # 7504

@stevencl @ bgashler1 Bitte wiegen Sie die Registerkarten erneut ab, und denken Sie daran, dass ich keine vernünftigen Standard-Tastenkombinationen für die Aktionen focusNext und focusPrevious des Terminals finden konnte (ich binde Strg + Umschalt + j / k).

Wir müssen dies jedoch im Zusammenhang mit diesem Problem berücksichtigen: https://github.com/Microsoft/vscode/issues/9659

Ich bin wirklich vorsichtig mit Tabs innerhalb des Tabs-Designs. Wir werden am Ende nur den gesamten verfügbaren Platz nutzen, um Registerkarten anzuzeigen :-)

Müssen wir hier nur laut nachdenken, müssen wir wirklich Tabs anzeigen, wenn wir das Terminal aufteilen dürfen? Wäre es ausreichend, wenn wir nur Aktionen zum Teilen und Reduzieren des Terminals verfügbar machen würden, aber nicht die tatsächliche Registerkarte anzeigen müssten?

Vielleicht kann ich mir vorstellen, 2-3 geteilte Terminals über Tabs / mehrere Terminals zu verwenden. Das Verwalten von Split-Terminals und Tabs-Terminals würde sehr verwirrend werden und wahrscheinlich aufgrund fehlender Tastenkombinationen kaum Verwendung finden.

Wenn wir die Tür zum Teilen von Terminals öffnen, was würde es für das Teilen von z. B. einem Terminal und einer Debug-Repl bedeuten? ist es die gleiche UX-Interaktion?

@bpasero durch Teilen Ich meine, ein neues Terminal an der Seite erstellen, also ja, es wäre das gleiche.

Um die Interaktion zu vereinfachen, könnte es eine Einstellung geben, bei der immer entweder das Dropdown-Menü verwendet oder die Terminals aufgeteilt werden. Auf diese Weise funktionieren alle vorhandenen Befehle weiterhin einwandfrei. Sie können jederzeit nur 1 oder alle Terminals anzeigen.

Die Angst, die ich beim Einführen von Registerkarten und beim Aufteilen in das Terminal habe, besteht darin, dass es wie eine Editorgruppe aussieht. Ich möchte nicht, dass Benutzer enttäuscht werden, dass sie keine Editoren in das Terminal oder Terminals in die Editorgruppen ziehen können. * Die Einführung dieser Option kann auch eine schlüpfrige Neigung in der Fensterverwaltung sein, z. B. warum wir überhaupt eine spezielle Horizontale haben Panel für solche Dinge in erster Linie. Lassen Sie ein Terminal einfach dort leben, wo es möchte, anstatt so viele Funktionen in der benutzerdefinierten Benutzeroberfläche zu replizieren.

* Möglicherweise können wir sie über die Einschränkung informieren, indem wir das Ziehen auf der x-Achse sperren und / oder einen deaktivierten Cursor verwenden, wenn wir versuchen, außerhalb eines Bereichs zu ziehen. Es ist jedoch schwierig zu vermeiden, dass Personen erwarten, dass dies funktioniert.

Wenn wir die horizontale Aufteilung von Editorgruppen einführen, besteht eine der Einschränkungen darin, dass Editorgruppen nur horizontal oder vertikal aufgeteilt werden können. Daher kann es für Benutzer unheimlich sein, ein Bedienfeld unter vertikalen Editorgruppen zu haben, das einer horizontalen Editorgruppe auffallend ähnlich sieht (sich aber nicht genau so verhält).

Wir sollten während der UX-Synchronisierung am Mittwoch mehr darüber sprechen. Es gibt einige Designs, die ich beim letzten Mal nicht gezeigt habe, im Zusammenhang mit horizontalen Layouts, die dafür relevant sind

Was ist mit der Option, das Terminal an der Registerkarte "Editor" auszurichten, sodass das Terminal automatisch die Sprache der Editordatei widerspiegelt?

Durch das Öffnen eines Terminals wird automatisch eine vorkonfigurierte Shell für die Sprache des aktiven (aktuell ausgewählten) Editors geladen. In der Datei settings.json müssen mehrere Terminal-Shells unterstützt werden.

Es spielt keine Rolle, wie die Editoren aufgeteilt sind - das Terminal zeigt immer die Shell für den ausgewählten (aktiven) Editor an. Dies ist einfach und unkompliziert. Bei dieser Methode ist es nicht erforderlich, das Terminal zu teilen, und es sind keine Terminals mit Registerkarten erforderlich. Das Terminal wird weiterhin so angezeigt wie jetzt.

Wenn für die Sprache mehrere Shells verfügbar sind oder Sie eine Konfiguration wie die Node- Shell und eine Git- Shell für die Registerkarte "Ein Editor" ausführen möchten, können die Shells möglicherweise in einem Bereich ausgewählt werden. Dies ist ein bisschen wie bei Terminals mit Registerkarten, außer dass sie nicht als harte Registerkarten dargestellt werden, was einen Unterkontext impliziert. Dies fühlt sich nicht wesentlich an wie ein Tab. Ihr Kontext befindet sich im Terminalbereich für den aktuell ausgewählten Editor.

Eine einfache Hypertext-Zeichenfolge (eine für jede Shell) oben rechts im Terminal zeigt die Shells an, die für den aktuell ausgewählten Editor geöffnet (instanziiert) sind. Ein Benutzer kann entweder einfach auf eine Hypertext-Zeichenfolge klicken, z. B. Knoten, um sie auszuwählen, oder eine Schlüsselbindung zum Durchlaufen verwenden. Diese ersetzen das vorhandene Dropdown-Menü, das + und den Papierkorb. Die Muscheln könnten möglicherweise in Kleinbuchstaben dargestellt werden.

Entweder könnte eine einfache Hypertext-Zeichenfolge angezeigt werden oder nur ein Symbol - obwohl eine Zeichenfolge möglicherweise besser ist. Dies würde die derzeit in VSCode verwendete umständliche Dropdown-Liste ersetzen und die Shells auf einen Blick anzeigen.

Wenn Sie den Fokus vom aktuellen Editor auf einen Editor mit einer anderen Sprache (z. B. Ruby) umschalten, zeigt das Terminal die IRB-Instanz im Terminal an. Wenn der Benutzer eine andere Instanz der aktuellen Shell öffnen möchte, muss er möglicherweise nur mit der Maus über den Hypertext für diese Shell fahren und auf das + klicken, das

Wenn Sie mit der Maus über eine Shell fahren, kann möglicherweise auch ein Peak angezeigt werden, der den Shell-Inhalt für diese Zeichenfolge anzeigt. Wenn Benutzer Tastenkombinationen zum Wechseln / Wechseln verwenden, ist es möglicherweise einfacher, dies zu überprüfen.

Wenn Sie dem Benutzer die Option geben möchten, eine Shell hinzuzufügen, die nicht dem Editor zugeordnet ist, wie z. B. eine Git-Shell, kann durch Klicken auf + ein Menü mit Shells angezeigt werden, die in der Datei settings.json registriert sind. Das - das beim Hover neben jeder Hypertext-Zeichenfolge angezeigt wird, zeigt natürlich keine Optionen an. Es würde die aktuelle Shell-Instanz schließen.

Wenn ein Benutzer den Shell-Typ ändern möchte, kann er die Shell verlassen (um auf die Standardeinstellung zurückzugreifen) und dann eine neue Shell starten, indem er den Shell-Namen eingibt. Die Hypertext-Zeichenfolge, die die Shell darstellt, würde sich ändern, um die neue Shell widerzuspiegeln.

Im Fall einer Git-Shell kann es logisch sein, dem Benutzer die Option anzubieten, anzugeben, dass eine Git-Shell immer mit der Sprach-Shell des Editors geöffnet wird, sodass sich Git im Kontext zu diesem Dateispeicherort befindet. Wenn mehrere Dateien vom selben Git-Speicherort geöffnet sind, spiegeln alle Git-Shell-Instanzen in allen Editoren das neueste Update oder den neuesten Befehl wider.

Für die Datei settings.json muss der Benutzer wahrscheinlich die spezifische Spracherweiterung (.js, .cs, .rb) für jede terminal.internal.shell eingeben. Eintrag, damit eine logische Übereinstimmung mit einer Datei besteht. Eine Standard-Shell kann für jeden Dateityp konfiguriert werden, der nicht in settings.json angegeben ist.

Die für jeden Editor geladene Shell-Instanz hält so lange an, wie dieser Editor geöffnet ist. Sobald ein Editor (eine Datei) geschlossen wird, werden auch die zugehörigen Terminal-Shell (s) geschlossen.

Ich glaube, dass dies eine einfache Implementierung ist, die VSCode auch leistungsfähiger als derzeit macht und gleichzeitig sehr intuitiv ist. Wenn der Benutzer die Kontexte zwischen den Spracheditoren wechselt, muss er nicht an das Terminal denken. Das Terminal zeigt immer die Shell und den zuletzt ausgeführten Code an, einschließlich des zugehörigen Verlaufs usw., der zuletzt für den ausgewählten Editor verwendet wurde.

@ nick-walt Während es für einige vielleicht intuitiver ist, ist es für andere überhaupt nicht intuitiv. Es würde wahrscheinlich dazu führen, dass die Leute etwas desorientiert werden und sich fragen, wohin ihre Muschel ging. Meine Anforderungen sind auch, dass 2 Muscheln gleichzeitig angezeigt werden. eine für eine Überwachungsaufgabe, in der ich Fehler verfolge, und eine für eine Startaufgabe, Git, Build usw.

Es wurden bereits mehrere Terminalkonfigurationen durchgeführt. Ich bin mir jedoch nicht sicher, ob sich die zusätzliche Komplexität lohnt, wenn Sie die Shell die meiste Zeit nur in Ihrer anderen Shell ausführen können (öffnet Powershell, Ruby, Node usw. innerhalb von cmd).

@ Tyriar
Das sind gute Bedenken, aber ich denke, dass sie ziemlich leicht gelöst werden können, wenn man sie als Überlegungen betrachtet.

Vermeiden Sie Orientierungslosigkeit
Im Standardzustand kann sich das Terminal bei einer nicht konfigurierten Neuinstallation auf vertraute Weise verhalten. Dies vermeidet die Desorientierung durch ein unerwartetes Verhalten.

Terminal aufteilen
Durch das Teilen des Terminalbereichs wird das Modell nicht geändert. Es ist nur eine Möglichkeit, mehr als eine Shell gleichzeitig im Terminalbereich anzuzeigen. Möglicherweise können Sie den Bereich aus dem Hauptfenster ziehen und auf einem anderen Monitor im Vollbildmodus angezeigt werden. Dann kann der Benutzer das Terminal anweisen, sich automatisch und gleichmäßig vertikal oder horizontal zwischen den offenen Schalen aufzuteilen. Ein Terminal, mehrere Shells - alles im Kontext des aktuell ausgewählten Editors.

Aufpassen
Wenn wir eine Shell-Instanz, die wir gerade beobachten, nicht aus den Augen verlieren möchten, während Sie zu einem anderen Editor wechseln, kann dieses Problem möglicherweise durch eine Überwachungsfunktion gelöst werden, die eine konfigurierbare Anzahl von Zeilen anzeigt. Wenn ein Fehler auftritt, kann dieser auch als Symbol angezeigt werden, falls der Benutzer ihn aufgrund des schnellen Bildlaufs verpasst hat. Dies erfolgt bereits im Fehlerbereich von VSCode. Ein Beobachtungsfeld kann nur angezeigt werden, und wenn Sie mit der Maus darüber fahren, wird möglicherweise eine größere Stichprobe angezeigt.

Raffinesse ohne Komplexität
Mit einem kontextbezogenen Terminal wird sich die Fähigkeit, viele Shells in all Ihren Editoren zu haben, nicht überwältigend oder anstrengend anfühlen. Mit dem richtigen Modell können die UI / UX-Leute dafür sorgen, dass es elegant funktioniert.

Ich denke, Ihre Bedenken könnten vollständig ausgeräumt werden.

Es hängt davon ab, welches Terminal verwendet werden soll (soll). Wenn damit ein einmaliger Befehl ausgeführt werden soll, werden in keiner Weise mehrere Terminals benötigt.

Es werden mehrere Terminals benötigt, wenn mehrere Hintergrundaufgaben gleichzeitig ausgeführt werden sollen, z. B. Serving, Building, Watching, Tests usw.

In diesem Fall ist es also möglich, einen schnellen Überblick darüber zu erhalten, welche Terminals geöffnet sind und was sie laufen (vermutlich mit dem Status des Laufs). Ich bin nicht sicher, wie es ohne benannte / erstellte Registerkarten gemacht werden kann .

Eine geteilte Ansicht ist ebenfalls erforderlich, da auf einem Breitbildschirm mindestens Platz für mehr als ein Terminal verfügbar ist.

Eine weitere Frage ist die kooperative Verwendung mit Task Runner. Welches wird derzeit verwendet, um jeweils nur eine Aufgabe auszuführen. Bei diesem https://github.com/Microsoft/vscode/issues/981 wird jedoch davon

Jetbrains Webstorm currenlty verfügt über solche Funktionen - es kann mehrere Aufgaben (definiert über grunt / gulp / npm) und mehrere Terminals (mit benannten Registerkarten) ausführen. Sie können dort auch eine geteilte Ansicht verwenden, in der auf einer Seite Aufgaben ausgeführt werden und auf der anderen das Terminal. (Anbringen des Bildschirms)

@weiße Farbe

Okay, wenn wir alle Szenarien und ihre Gemeinsamkeiten auflisten, sollte es möglich sein, die erforderliche Funktionalität auf Eleganz zu bringen, die unterschiedliche Verwendungszwecke adressieren kann - ohne dass VSCode zu schwer wird.

Viel Tabs ohne Müdigkeit
Bei einem Terminal, das an den Kontext eines Editors gebunden ist, ermöglicht das Problem einer Trennung der Benutzerfreundlichkeit (z. B. welche Registerkarten welchem ​​Editor zugeordnet sind) die Verwendung von "weichen Registerkarten", auch bekannt als Hypertext-Zeichenfolge, die die Shell im Terminal- / Editor-Kontext benennt viele weitere Registerkarten, ohne dass der Benutzer auf Registerkartenjagd geht, und vermeiden, dass Kontext- / Assoziationsermüdung den Überblick behält.

Benannte Muscheln
Mit der Idee einer einfachen Hypertext-Zeichenfolge, die den Namen einer Shell-Instanz in einem Terminalbereich anzeigt, besteht die Möglichkeit einer alternativen Erstellung und Benennung. Ein Benutzer hat also eine einzelne Shell in settings.json konfiguriert, die möglicherweise 'cmd' lautet.

Sobald sie sich in einer Shell befinden, können sie entweder in eine andere Shell wie 'Powershell' oder 'Bash' springen, und die Hypertext-Zeichenfolge mit dem Namen 'cmd' im Terminal-Header kann sich ändern, um die Shell widerzuspiegeln, zu der der Benutzer gesprungen ist.

Oder der Benutzer kann eine zusätzliche Shell-Instanz aus der Starter-'cmd'-Shell erstellen, indem er möglicherweise einen Befehl verwendet, den das Terminalfenster als "neu" versteht".

Die Idee ist, in der Benutzeroberfläche die Tatsache zu implizieren, dass die benannten Shells keine nicht zugeordneten Registerkarten sind, sondern Shells im übergeordneten Editor. Ich verwende den Begriff "Tabs", um eine nicht zugeordnete und in sich geschlossene Shell zu bezeichnen, die von allem anderen getrennt ist. Dies kann ein Modus sein, in dem Hard-Tabs global sind und Soft-Tabs sich in einem Editor-Kontext befinden.

Wenn ein Hard-Tab- / Soft-Tab-Modus enthalten wäre, könnten die Hard-Tabs möglicherweise Hard-Boarder haben, ähnlich wie Tabs mit Editoren. Das Verhalten der Namen wäre identisch mit Soft-Tabs.

Entscheidend ist, das etablierte UI / UX-Modell beizubehalten. Wir haben alle viele Fälle gesehen, in denen Modelle in einer einzigen App auf verschiedene UI-Implementierungen verteilt sind. Eigentlich ist Microsoft gut darin (und in letzter Zeit auch Apple). Es ist ein klassischer Fall von "Design by Committee".
etabliert

Einfacher Single-Shell-Benutzer
Wenn ein Benutzer jedoch ein vereinfachtes und ein einzelnes Terminal / eine einzelne Shell ausführen möchte, steht dies nicht im Wege, und vor allem ist die Konfiguration einfach. Es ist nur ein weiteres Verwendungsszenario in der Betrachtungsmatrix.

Wenn Registerkarten hinzugefügt werden sollen, hätte ich gerne eine Konfigurationsoption, um sie zu deaktivieren / eine einzelne Instanz des integrierten Terminals zu erzwingen. Wenn ich solche erweiterten Funktionen benötige, greife ich normalerweise auf das (externe) Terminal meiner Wahl zurück.

Ich würde auch so etwas wie Terminal Split (Advanced Split) in Betracht ziehen, damit alle laufenden (vielleicht mehr als zwei) wichtigen Terminals nur teilweise vor den Augen ausgegeben werden.

Wie wäre es, wenn Sie die Terminal-Registerkarten an derselben Stelle wie die Datei-Registerkarten anzeigen?
Es würde die Benutzeroberfläche nicht verschmutzen und keine funktionale würde verloren gehen.

@cescoferraro Ich mag diese Idee. Dann sollte VS Code aber auch vertikale geteilte Registerkartenansichten unterstützen und nicht nur horizontal. Andernfalls würde es nicht wirklich die Bedingung erfüllen, mehrere Terminals zu sehen, ohne Platz zu verschwenden.

@Phisherman Versteh mich nicht falsch, ich mag das Split-Terminal.
Ich benutze es viel auf Intellij mit einem großen Bildschirm und viel Speicher-Setup.
Was auch immer die Entscheidung ist, es sollte steckbar sein, wenn zu viel Speicher benötigt wird, um VSCode so schnell wie möglich zu halten.

Ich habe eine Erweiterung geschrieben, mit der Sie die Aufgabe npm / gulp auswählen können. Sie startet das Terminal (mit dem Namen der Aufgabe) und führt es dort aus. Außerdem wird ein Element in der Statusleiste platziert, auf das Sie jederzeit klicken können Verfolgt die grundlegende Verfolgung des laufenden Prozessstatus.

Nur um die mögliche Position der "Tabs" anzuzeigen, könnten sie sich am unteren Rand des Teminals befinden.

@whitecolor : open_mouth: verwendet dies die neue Terminal-API? Das ist großartig!

@ Tyriar Ja, das, an dem du

Wie von @whitecolor erwähnt , verfügt WebStorm über Registerkarten für Terminals,

Was WebStorm jedoch nicht tut, ist, dass die Anzahl der geöffneten Terminal-Registerkarten nicht gespeichert wird.
Bei der Entwicklung benötigen Sie normalerweise dieselben Registerkarten (Server, Watcher, Backend ...). Wenn die Anzahl der Registerkarten sowie deren Name gespeichert werden könnten, wäre dies fantastisch.

@whitecolor Nachdem Sie ein wenig darüber nachgedacht haben, gibt es einige Probleme, die Sie mit der aktuellen API beim Implementieren von Terminal-Registerkarten auf diese Weise haben werden, vorausgesetzt, Sie legen einen Erweiterungsbefehl "Neues Terminal erstellen" offen, den Sie den Standardbefehl überschreiben möchten. Hier sind einige Probleme, die Sie verfolgen sollten, wenn Sie eine Erweiterung wie diese erstellen möchten:

• Wenn vscode neu gestartet wird, wird ein Standardterminal erstellt. Sie können diesem kein Statusleistenelement hinzufügen
• Die Erweiterung weiß nicht, wann ein Terminal vom Benutzer entsorgt wird, sodass das Element in der Statusleiste mindestens so lange erhalten bleibt, bis erneut auf # 10925 geklickt wird
• (Fehler) Wenn Sie ein Terminal entsorgen, wird das Bedienfeld Nr. 11275 angezeigt
• In Version 1.6.0 wird das Terminal wahrscheinlich standardmäßig ausgeblendet, sodass Sie direkt nach dem Erstellen von # 11384 Terminal.show aufrufen müssen

@ Tyriar danke für das Teilen, wird auf

1) Ja, es ist nicht so wichtig, meine Erweiterung fügt tatsächlich einen Befehl "Neues Terminal öffnen" hinzu und ermöglicht das Öffnen eines neuen benannten Terminals. Normalerweise schließe ich nur den Standard und verwende ein erstelltes, aber es wäre gut, wenn es einen Zugriff auf gäbe alle vorhandenen Terminals im Panel.
2) Ja, die Erweiterung kennt den Terminalstatus nicht, aber ich verfolge untergeordnete Prozesse von terminal._id anhand der PID. Ich weiß also, wann das Terminal vom Benutzer entsorgt wird (untergeordnete Prozesse gehen auf 0). Also, was ich bitten würde, diese Prozess-ID in Zukunft nicht zu entfernen, nicht sicher, ob dies öffentlich sein muss). Ich verfolge sogar die Anzahl der ausgeführten untergeordneten Prozesse. Wenn die Anzahl verringert wird, kann dies bedeuten, dass etwas nicht stimmt oder die Aufgaben beendet sind. Dann zeige ich dieses Terminal, das sehr nützlich ist.
3) Also verwende ich derzeit nicht entsorgen.

Was wirklich fehlt, ist der Zugriff auf die Prozessausgabe, der es ermöglicht, nützlichere Analysen durchzuführen (z. B. die Ausgabe von Fehlern / Ausnahmen zu verfolgen) und das Terminal dem Benutzer anzuzeigen.

Die Erweiterung ist tatsächlich fertig, wird veröffentlicht, wird dies wahrscheinlich an Tagen tun.

@whitecolor Derzeit gibt es nur Zugriff auf Terminals, die über die API erstellt wurden. Dies ist jedoch ein überzeugender Fall, um dies zu ändern.

Sneaky Sneaky Peeking bei terminal._id : Wink: Es wird wahrscheinlich nicht so schnell geändert, aber sobald ein Ereignis hinzugefügt wird, das Sie anhören können, sollten Sie es auf jeden Fall nutzen, da es die offizielle stabile API sein wird. Die Verfolgung und Ausgabe von untergeordneten Prozessen ist in # 11422 zu untersuchen (Sie können die damit verbundenen Probleme für einige Diskussionen zu diesem Thema verfolgen).

Mit dem benannten Terminalbefehl bieten Sie auch eine Problemumgehung für # 10023: smiley:

Gute Arbeit, ich freue mich darauf, es auszuprobieren!

@whitecolor FYI, also habe ich gelogen und terminal._id wird sich wahrscheinlich in Version 1.6 ändern, um eine zufällige ID zu sein, nicht die PID. Ich bin mitten in einem riesigen Refactor, um das Terminal-Panel mehr von den Prozessen zu trennen (damit sie existieren können, ohne dass das Panel # 11275 existiert), und ich glaube nicht, dass ich es dort leider behalten kann.

@whitecolor können Sie window.onDidCloseTerminal (# 10925) in den Insidern von morgen ausprobieren. Es sollte einfacher sein als die PID zu verfolgen.

Ich würde es gerne wie InteliJ sehen. Bis dahin füge ich ihm diese persönlichen Tasten hinzu:

[
    {
        "key": "ctrl+pageup",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },{
        "key": "ctrl+pagedown",
        "command": "workbench.action.terminal.focusPrevious",
        "when": "terminalFocus"
    }
] 

Dieselben Tastaturkürzel zum Navigieren zwischen Registerkarten, aber wenn sich der Cursor auf das Terminal konzentriert, wechseln Sie zwischen den Terminals.

Eine geteilte Ansicht auf den Terminal-Registerkarten wäre sehr nützlich.

Ich versuche derzeit, einen Proof of Concept mit einer Serverinstanz durchzuführen und Anforderungen über ein anderes Konsolenterminal auszuführen.

Irgendwelche Fortschritte in diesem Bereich?

@ MeirionHughes
tmux könnte eine Lösung sein, funktioniert aber im integrierten VSCode-Terminal ungünstig (endlich in Windows).

@MeirionHughes Hier ist das Problem für diese Funktion: https://github.com/Microsoft/vscode/issues/7504. Bisher keine Fortschritte, als ich das letzte Mal darauf drängte, wurde ich vom Team zurückgedrängt. Je mehr: +1: zu diesem Thema, desto besser.

@ Tyriar könnte man sagen, dass dieses Problem auch nach einer Aufteilung fragt, da es im dritten Bild explizit gezeigt wird. Plus diese Ausgabe hat 112 👍 :)

@ MeirionHughes der erste Kommentar (meiner) sagt:

Verfolgen wir die Aufteilung des Terminals in # 7504

Der Grund dafür ist, dass die Diskussionen für zwei verschiedene Funktionen kein gegenseitiges Rauschen verursachen.

Oh Leute, pls helfen, da es wirklich wichtige UI-Funktion ist, manchmal macht es crz Handle Dropdown, um die Konsole zu wechseln, vielen Dank;)

+1 für cycle terminal Tastenkombinationen.

@whitecolor _darn! _ Ich dachte, tmux innerhalb des integrierten Terminals sei meine eigene clevere Problemumgehung, aber du hast mich geschlagen. Funktioniert gut für mich (keine mouse mode ), aber Fenster funktionieren gut:

Der Mausmodus funktioniert bei mir mit tmux einwandfrei.

Auf jeden Fall denke ich, dass dies eine großartige Ergänzung ist

Ich denke, das wäre wirklich nützlich. Ich denke jedoch nicht, dass es sich auf Terminals beschränken sollte, sondern auch die Registerkarten "Probleme", "Ausgabe" usw., sodass Sie "Terminal", "Probleme" und einen Editor in einer Ansicht öffnen können.

Ich werde auch nur +1 auf einer Tastenkombination, um durch die Terminals zu radeln. Ich hasse es, mit der Maus auf dieses winzige Dropdown klicken zu müssen, besonders auf einem Laptop mit Trackpad.

Geben Sie mir eine Tastenkombination, um durch die Terminals zu blättern, und ich denke, ich kann auf die Aufteilung / Tabs verzichten

@ psimoneau22 das ist die

{ "key": "ctrl+shift+j",    "command": "workbench.action.terminal.focusNext" },
{ "key": "ctrl+shift+k",    "command": "workbench.action.terminal.focusPrevious" },

Wir werden uns bald mit der Spaltung befassen.

Ich kann nicht glauben, wie gut und mächtig dieser Editor wird. Dies ist eine super leistungsstarke Ergänzung, um nur vscode und nichts anderes während einer Codierungssitzung zu öffnen.

TL; DR; Verwenden Sie einige Stunden, um tmux aufzunehmen.

Ich bin mit tmux in meinem Terminal zufrieden (der Mausmodus funktioniert wie ein Zauber). Ich habe einen Tag gebraucht, um zu lernen. Ich habe schon ein paar Mal damit gespielt, aber ich habe gestern damit verbracht, es wie einen Boss aufzubauen. Ich mache einfach ein tmux -CC in iTerm - das ein Terminalfenster öffnet. Führen Sie dann im vscode-Terminal ein tmux a aus, um eine Verbindung zu dieser Sitzung herzustellen. Auf diese Weise erhalte ich permanente Terminalsitzungen, sodass ich beim Neustart von vscode immer nach Sitzung zurückkehren kann (Vscode aktualisieren, Erweiterungen installieren). Dies ist für mich eine viel bessere Funktion als Tabs oder Splits im Terminal. Halten Sie bitte Vscode-Licht. Atom ist eine Lektion, aus der man lernen kann (ich bin daraus gekommen). TMUX FTW :)

Der gleiche Ansatz hat auch bei Mac / Cygwin / Windows funktioniert und sollte praktisch überall dort funktionieren, wo Vscode ausgeführt wird.

TL; DR;

Es wäre schön, Registerkarten für das integrierte Terminal anstelle der Dropdown-Liste zu haben. Gibt es eine Chance, diese Funktion in Zukunft zu sehen?

In Anbetracht der Tastenkombination Strg + Umschalt + ` und Strg + ` halte ich diese Einstellungen für sinnvoller.

  {
        "key": "ctrl+shift+right",
        "command": "workbench.action.terminal.focusNext"
    },
    {
        "key": "ctrl+shift+left",
        "command": "workbench.action.terminal.focusPrevious"
    }

@leocaseiro @Tyriar @ psimoneau22 Sofern Sie keinen Mac verwenden, lohnt es sich, die Option "Wann" zu den Optionen ctrl + shift + left und ctrl hinzuzufügen shift + right werden verwendet, um Textblöcke im Editor auszuwählen.

    {
        "key": "ctrl+shift+j",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+shift+k",
        "command": "workbench.action.terminal.focusPrevious",
         "when": "terminalFocus"
    }

oder

    {
        "key": "ctrl+shift+right",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+shift+left",
        "command": "workbench.action.terminal.focusPrevious",
         "when": "terminalFocus"
    }

Hier ein my 2ct für diese sehr wünschenswerte Funktion (sorry, wenn einige der Punkte bereits erwähnt wurden)

Anwendungsfälle
Der Grund, warum ich im ersten Fall mehrere Terminals verwende, ist normalerweise entweder:

• Ich muss in zwei Verzeichnissen parallel arbeiten und möchte nicht die ganze Zeit vorwärts und rückwärts cd
• Ich muss mit zwei verschiedenen Terminals arbeiten (zB bash vs Powershel vs cmd oder local vs remote / ssh)
• Ich möchte die Ausgabe von zwei verschiedenen Programmen parallel überwachen

Beachten Sie, dass ich nur im dritten Fall eine geteilte Ansicht des Terminals benötige. In den meisten anderen Fällen bevorzuge ich ein Terminal, das so viel Platz wie möglich beansprucht.

Benutzeroberfläche
Erweitern Sie die aktuellen Registerkarten (z. B. Debugging, Ausgabe, Terminal ...) und lassen Sie ein zusätzliches "Terminal1, Terminal2, Terminal3 ...." zu.

Tabs vs Dropdown

• Sie sehen alle verfügbaren Registerkarten
• Es fällt mir (für mich) leichter, mich daran zu erinnern, welches Terminal welchen Zweck erfüllt, wenn es durch unterschiedliche visuelle Standorte dargestellt wird (z. B. 3. Registerkarte).

tl; dr

Ich stimme @MikeGitb sehr zu , ich benutze immer mehr als 1 Terminal gleichzeitig. Das Dropdown-Menü für Terminals im aktuellen VS-Code ist in offenen Registerkarten nur schwer zu erkennen. Es wäre wirklich großartig, Registerkarten für ein integriertes Terminal zu haben. Vielen Dank.

Eine verrückte Idee: Warum nicht dem Terminal den gleichen Status wie den normalen Editor-Registerkarten geben? Wäre besonders praktisch, wenn man mehr als ein paar Zeilen gleichzeitig sehen möchte.

Eine verrückte Idee

Es ist nicht verrückt, so funktionieren Vim / Neovim.

Es ist nicht verrückt, so funktionieren Vim / Neovim.

Wie viele andere IDEs;).

Entschuldigung, dieses Intro war eigentlich ironisch gemeint.

@ Tyriar Gibt es eine Funktion, mit der das Terminal neben Ihrem Code vertikal verschoben werden kann, oder ist dies nicht zulässig?

@ajrator , der in https://github.com/Microsoft/vscode/issues/2806 behandelt wird

Würde mich sehr freuen, Terminals den gleichen Status wie Editor-Registerkarten zu geben - ComEmu und HyperTerminal haben beide schwerwiegende Probleme, die ihre aktuelle Verwendung verhindern (ConEmu hat Kontrastprobleme, die nicht behoben werden können, da der Betreuer die XP-Unterstützung beibehalten möchte, HyperTerminal nicht Strg + C in Powershell und anderen Grundlagen). Vscode als funktionierendes Terminal mit Registerkarten zu haben, wäre fantastisch.

Ich beobachte auch weiterhin, wann die Registerkartenansicht des integrierten Terminals anstelle der Dropdown-Liste veröffentlicht wird.

Das Dropdown-Menü ist etwas unangenehm zu bedienen. Es wäre auch großartig, mehr als ein offenes Terminal zu haben.

Für Leute, die tmux ausprobieren
https://gist.github.com/cybertim/e8b42c8cd8a5bebaa3eb8cec17a2746f

Danke @cybertim , tolle Datei! Ich habe tmux bereits verwendet, aber diese Datei ist praktisch.

Der Grund, warum ich persönlich sehr an mehreren Terminals an unterschiedlichen Positionen innerhalb des Fensters interessiert wäre, ist, dass dies hoffentlich den Weg zur Implementierung einer RStudio / Jupyter Lab-ähnlichen Umgebung in VSCode weisen würde.

Persönlich möchte ich, dass alles eine Registerkarte ist und dann die Möglichkeit bietet, Panels unendlich vertikal und horizontal zu teilen. Sie können dann auch Registerkarten anheften, um die am häufigsten verwendeten Tools wie Terminal, Explorer und Suche beizubehalten.

Ältere Editoren haben die Schaltflächen zum Speichern, Rückgängigmachen und Wiederherstellen entlang einer langen Symbolleiste oben - VSCode nicht - warum? Weil erwartet wird, dass die Leute die Tastatur benutzen würden. Wir sind Programmierer. Vorheriges Terminal, nächstes Terminal Alle können an Tastenkombinationen gebunden werden - verwenden Sie es. Ich sage, wir schließen dieses Problem und fahren mit dem fort, was wichtig ist.

Als nächstes möchten Sie noch Tabs? Scheiben? Splits?

Ich denke, viele Leute hier fordern eine Funktion an, die für VScode übertrieben ist. Wenn sie nur tmux ausprobieren würden, würden sie nicht danach fragen. Das Terminal wird uns gegeben. Mit tmux werden Registerkarten unterstützt. Sie werden maximal ein paar Stunden brauchen, um tmux zu lernen. Es gibt Registerkarten, Fenster, Teilungen und vieles mehr. Wenn Sie VSCode neu starten müssen, können Sie nach dem Neustart einfach tmux -a eingeben, um direkt zu Ihrer tmux-Sitzung zurückzukehren. Nach dem Einschalten des Mausmodus (nur eine Zeile in der Konfiguration) können Sie sogar die Größe von Fenstern ändern. Klicken Sie auf Registerkarten, um zu dieser Registerkarte zu gelangen. Ich bin gegen diese Funktion in VSCode. Es wird nur die Leistung verlangsamen. Halten Sie VSCode so leicht wie möglich - wir wollen kein weiteres Atom. Lassen Sie tmux das schwere Heben machen! Wie Sie unten sehen können, habe ich Teilungen und auch wenn Sie sich den unteren Bereich genau ansehen, habe ich zwei Registerkarten - python & fish . Und ja, unten links verwende ich Googler in der Befehlszeile von Google: D.

@piggyslasher Ich sehe nicht, wie diese Funktion vscode langsamer machen könnte.
Vscode unterstützt bereits mehr als eine Terminalinstanz. Bei dieser Funktion geht es nur darum, die Dropdown-Auswahl in eine hoffentlich schönere Tab-Funktion zu ändern.

Mit dieser Funktion können Sie weiterhin eine Terminalinstanz / Registerkarte mit tmux verwenden und erwarten keine Leistungsänderung im Vergleich zu jetzt.

Vscode ist ein Multi-Plattform-Editor. Wenn Sie den Benutzern sagen, dass sie tmux verwenden sollen, beschränken Sie sich auf Umgebungen, in denen tmux verfügbar ist. Außerdem hat tmux eine große Lernkurve, die für eine so einfache Funktion wie diese völlig übertrieben ist

Der Vorschlag von

Darüber habe ich schon lange nachgedacht. Tmux hat tabs und jedes tab kann in so viele panes wie es möchte. Im Gegensatz dazu haben Redakteure panes und dann kann jeder pane tabs .

Ich mag den tmux-Weg eher, weil es so aussieht, als ob 'dieses Layout von Terminals verwandt ist und wir dann zu einer anderen Registerkarte verwandter Terminals wechseln'.

Für etwas wie Reagieren / Winkelentwicklung könnte ich dies nützlich finden, wenn Sie für jede Komponente einen JS / HTML / CSS / Test-Bereich und für jede Komponente, an der Sie arbeiten, einen Tab öffnen.

Es würde mich interessieren, ob es möglich ist, so etwas in einem Plugin zu tun. Origami for Sublime ist nah dran, aber es sind immer noch "Fenster voller Registerkarten", nicht "Registerkarten voller Fenster".

Es gibt große Bedenken hinsichtlich des Umfangs und des Umfangs der Einführung der Konsolenverwaltung über Registerkarten und andere Benutzeroberflächenmechanismen, und ich möchte nur darauf hinweisen, dass, wenn das zu lösende Problem sehr klar definiert ist, Probleme mit dem Umfang und dem Umfang des Ausblasens und der Benutzererwartung auftreten aufgrund der Eleganz der Lösung gemildert werden. Definieren Sie das Problem sehr klar und die Lösung wird klarer, und es ist wahrscheinlicher, dass die Logik in der gesamten Benutzeroberfläche und UX konsistent ist. Sie wissen, dieses Gefühl von "es funktioniert einfach", das wir alle gerne nutzen und kreieren.

Es wäre auch gut, eine Liste mit Aufzählungszeichen oder Nummern der verschiedenen in diesem Thread angebotenen Lösungen und ihrer identifizierten Bedenken zu haben (wahrscheinlich als eingerückte Aufzählungszeichen / Zahlen). Ein Thread wie dieser kann sich im Kreis drehen, ohne dass diese Dinge an einem zentralen, kuratierten Ort oder vielleicht im ersten Beitrag aktualisiert werden.

Mir scheint, dass sich alle einig sind, dass eine Form der Konsolenverwaltung erforderlich ist, die über das derzeitige Maß hinausgeht. Nur ein Vorschlag zur Lösung von Skalierungsproblemen: Bieten Sie dem Benutzer die Möglichkeit, die Konsolen an einen Editor oder eine Gruppe von Editoren anzuhängen. Ermöglichen Sie auch, dass eine Konsole getrennt ist, aber machen Sie in beiden Fällen einen benutzerdefinierten Standard in den Einstellungen. Durch das Anhängen der Konsolen an den Editor-Kontext wird das übermäßige Laichen von Konsolen verringert. Außerdem können die Konsolen eines Editors ausgeblendet werden, wenn ein anderer Editor ausgewählt wird, wodurch die Komplexität der Benutzeroberfläche gering gehalten wird. Wenn Konsolen nicht mit Editoren verknüpft sind, können die Dinge außer Kontrolle geraten und die Leute werden vergessen, welche Konsole was tut usw.

Erwägen Sie das Hinzufügen einer vom Benutzer konfigurierbaren Einstellung, mit der die für einen Editor definierten Konsolen in der App gespeichert werden können, basierend auf dem Namen und dem Speicherort der Datei (oder möglicherweise basierend auf einer anderen, zuverlässigeren und eindeutigeren Kennung in den Dateieigenschaften unter) System Level).

Man könnte sagen, dass sich diese Verfeinerungsebene der IDE-Ebene nähert, aber die Entwickler haben bereits gesagt, dass VSCode einige der guten Dinge einer IDE in den Editorbereich bringt. Es ist möglich, eine Konsolenlösung einzuführen, die sich nicht schwer oder komplex anfühlt, die nur funktioniert und gleichzeitig eine hervorragende Benutzeroberfläche bietet.

Wenn dies keinen Sinn ergibt oder wenn ich das Offensichtliche sage, lassen Sie es mich wissen.

@ Nick-Walt, wenn du sagst:

Bieten Sie dem Benutzer die Möglichkeit, die Konsolen an einen Editor oder eine Gruppe von Editoren anzuhängen.

Schlagen Sie eine Möglichkeit für das Terminal vor, Shell-Instanzen bestimmten geöffneten Dateien zuzuordnen?

Klingt für mich so, als würden Sie es zu kompliziert machen. Natürlich denken Sie immer wieder darüber nach, aber nach dem, was ich bei ähnlichen Funktionen gesehen habe, hält das vscode-Team die Auswirkungen kleiner Funktionen wie dieser gerne so gering wie möglich. Ich wette, sie suchen nach der einfachsten (wenn auch immer noch effektiven) Lösung, um die Menschen glücklich zu machen.

Der grundlegendste Punkt dieses Problems ist, dass ein Dropdown-Menü nicht gut zum Wechseln zwischen Dingen geeignet ist und dass Registerkarten eine ziemlich gute Alternative sind - daher verwenden die meisten Dinge Registerkarten: Editoren, IDEs, Browser usw. Ich denke, jeder hier würde dem zustimmen dass im Wesentlichen jede Form von Registerkarten einem Dropdown vorzuziehen wäre.

Abgesehen von dem grundlegendsten Teil des Wechsels zwischen Shell-Instanzen besteht ein Interesse daran, auch zuzulassen, dass mehr als eine Instanz gleichzeitig sichtbar ist. Entweder durch Fenster im Terminalbereich unten oder indem Sie die Terminal-Registerkarten auf irgendeine Weise mit den Editor-Registerkarten austauschbar machen oder eine andere Lösung. Dieser Teil ist komplizierter und es besteht wahrscheinlich weniger Einigkeit darüber, welchen Weg wir gehen sollen. Vor allem, wenn man bedenkt , was Panes -Inside-Tabs und Tabs-Inside-

Persönlich denke ich, dass es genug Unterstützung gibt, um das Dropdown-Menü zu entfernen (weil es wirklich nicht großartig ist), es durch Tabs zu ersetzen und sich danach um fortgeschrittenere Dinge zu kümmern.

Vor über einem Jahr sagte @ bgashler1 Folgendes :

Die Angst, die ich beim Einführen von Registerkarten und beim Aufteilen in das Terminal habe, besteht darin, dass es wie eine Editorgruppe aussieht. Ich möchte nicht, dass Benutzer enttäuscht werden, dass sie keine Editoren in das Terminal oder Terminals in die Editorgruppen ziehen können. * Die Einführung dieser Option kann auch eine schlüpfrige Neigung in der Fensterverwaltung sein, z. B. warum wir überhaupt eine spezielle Horizontale haben Panel für solche Dinge in erster Linie. Lassen Sie ein Terminal einfach dort leben, wo es möchte, anstatt so viele Funktionen in der benutzerdefinierten Benutzeroberfläche zu replizieren.

Vielleicht ist es zu diesem Zeitpunkt am besten, Registerkarten in Betracht zu ziehen, die sich sichtbar von Editor-Registerkarten unterscheiden, um anzuzeigen, dass sie nicht mit Editor-Registerkarten austauschbar sind, um Verwirrung zu vermeiden?

Ich stimme zu, Tabs sind eine ziemlich gute Lösung für die Auswahl verschiedener Konsolen.

Ich denke, die Möglichkeit, die Funktionalität der Zuordnung von Konsolen zu einem Editor zu aktivieren, besteht darin, eine Benutzereinstellung zu ändern. Nach dem Aktivieren kann durch Öffnen einer Konsole bei Auswahl eines Editors die Zuordnung erstellt werden. So einfach ist das.

Die Benutzeroberfläche besteht höchstwahrscheinlich darin, dass sich bei Auswahl eines neuen Editors (einer neuen Datei) oben in der Anwendung die Konsolenregisterkarten unten ändern, wenn sich der Editor ändert. Es ist ziemlich einfach und intuitiv.

Ich denke, es würde nur komplexer werden, wenn sie die Möglichkeit hinzufügen, einzelne Konsolen mit mehr als einem Editor zu verknüpfen, basierend auf einem bestimmten Benutzerkontext, wie z.

• Verzeichnisverzeichnis
• Projekt
• Dateityp (möglicherweise, wenn sich die Dateien am selben Speicherort befinden)
• Editorgruppierung (benutzerdefiniert)
• eine andere Abstraktion

Diese Erfahrung besteht darin, dass die angegebene Konsole unabhängig vom ausgewählten Editor im Kontext gleich bleibt (oder gleich bleibt, weil der Benutzer möchte, dass alle Konsolen für alle Editoren verfügbar sind).

In der Darstellung der Benutzeroberfläche müssen die Dinge kreativ werden, um das Gefühl der Komplexität zu vermeiden und sie intuitiv, schnell und einfach zu bedienen zu halten. Bei gutem UI-Design ist die Komplexität nur für das Team vorhanden, das das Feature erstellt :)

Um die Zuordnung einer Konsolenregisterkarte zu einem Editor zu verstärken, wird der Bereich, der die Konsolenregisterkarten enthält, eindeutig mit dem Namen des Editors gekennzeichnet.

Und auf jeder Registerkarte kann automatisch der Typ der geladenen Konsole angezeigt werden, z. B. Git, Node, CMD, Powershell ... anstatt Terminal 1, Terminal 2 usw. (wie von @Perkovec gezeigt ). Dies würde automatisch von der Anwendung generiert.

Auf diese Weise kann der Benutzer direkt die gewünschte Konsole auswählen, ohne über die Registerkarten nach dieser Git- oder Powershell-Eingabeaufforderung suchen zu müssen.

Die andere Option besteht darin, die grundlegende Registerkarten-Engine im Anwendungskern bereitzustellen und Benutzern das Hinzufügen einer Erweiterung ihrer Wahl zu ermöglichen, um der Konsolenverwaltung weitere Funktionen hinzuzufügen. Irgendwann können die Funktionen, die häufig verwendet werden, in die Kern-App integriert werden.

Wenn ich Sie richtig verstehe, bin ich strikt dagegen, das Terminal mit Editorfenstern zu verknüpfen. Die meiste Zeit habe ich keine feste Beziehung zwischen Editor-Registerkarten und Terminals und wenn ich das tue, ist es sicherlich keine 1: 1-Zuordnung (normalerweise nicht einmal 1: N).

@MikeGitb Ich würde vermuten, dass je nach Gewicht der Benutzerpräferenz die Standardzuordnung des Editors zur Konsoleneinstellung entweder aktiviert oder deaktiviert sein kann.

Einige möchten möglicherweise beides mischen, je nachdem, was sie tun und welche Konsole sie verwenden. Dies ist nur eine Verfeinerung des UI / UX-Problems, das die Ersteller lösen müssten. Gleich wie bei jeder UI / UX-Herausforderung.

Der Anwendungsfall für den Kontexteditor / die Konsolen-UX lautet:

• kein Kontext (keine Konsolen, die einem bestimmten Editor zugeordnet sind)
• gemischter Kontext (einige Konsolen zugeordnet, andere nicht)
• der gesamte Kontext (alle mit einem Editor verknüpften Konsolen)

Übrigens schlage ich die Zuordnung einer Konsole zu einem Editor als Option vor, um die Verbreitung von Konsolenregistern (und unerwünschte Verwirrung / Overhead) zu minimieren, was ein Anliegen einiger Leute war. Bei einem kontextbezogenen Editor / Konsolen-UX werden die zugehörigen Konsolen höchstwahrscheinlich ausgeblendet, sobald ein Editor in einem anderen Kontext ausgewählt wird. Der Benutzer sieht immer nur das, was für den ausgewählten Editor relevant ist.

Wie üblich wird die UI-Implementierung so etwas machen oder brechen. Das VSCode-Team hat mit der Benutzeroberfläche bereits hervorragende Arbeit geleistet, und es gibt keinen Grund zu der Annahme, dass es nicht herausfinden konnte, wie eine anspruchsvollere Konsolenverwaltung implementiert werden kann, ohne dass sich die Dinge kompliziert und überlastet anfühlen.

Wie wir alle zuvor und zunehmend mit neuerer Software erlebt haben, ist es sehr gut möglich, den Benutzer einem wesentlich höheren Grad an Komplexität und Raffinesse auszusetzen, während die Erfahrung einfacher wird und sich einfacher anfühlt.

Nur um Ihren Anwendungsfall zu verstehen: Darf ich fragen, welche Art von Vorgängen Sie am Terminal ausführen, die an eine bestimmte Datei gebunden sind, im Gegensatz zum Projekt / Verzeichnis?

Meine typischen Anwendungsfälle sind die Verwendung von git, das Kompilieren meines Projekts, das Ausführen einer Binärdatei und das Anzeigen einiger Trace-Ausgaben. Alle von ihnen sind unabhängig davon, welche Datei gerade geöffnet ist, aber ich verwende sie hauptsächlich für C ++ - Projekte oder einzelne Dateibearbeitungen, sodass andere Bereiche möglicherweise andere Workflows erfordern.

Ziemlich sicher, dass fast jeder Terminalinstanzen unabhängig von den Editor-Registerkarten verwendet. Eine solche Funktion wäre als Erweiterung besser geeignet.

Ja, ich bin damit einverstanden, die Konsolenerfahrung um Erweiterungen zu erweitern. Wahrscheinlich der beste Weg, um diesen Bereich für die Entwicklung zu öffnen.

Das Erstellen einer Konsolen-Engine in VScode, auf die jeder aufbauen kann, wäre ein interessantes Experiment.

Hier ist ein Clip, wie die Cloud9-IDE funktioniert:

Es scheint das zu haben, wonach viele von uns zu suchen scheinen: Jede neue Registerkarte kann entweder ein Editor oder ein Terminal sein, und jede Registerkarte kann horizontal oder vertikal verschoben und geteilt werden.

@plmrry Das ist großartig! Etwas in diese Richtung wäre wirklich schön.

@plmrry Die Frage, ob wir ein so flexibles

Wenn auf den Registerkarten des Editors mehrere Terminals vorhanden sind, einige im Vordergrund, andere im Hintergrund, ist die Frage, was bestimmte Terminalbefehle tun, nicht so klar und nicht so intuitiv.

Können die Terminalbefehle nur auf den zuletzt fokussierten Befehl abzielen? Ähnlich wie cmd + shift + t auf die zuletzt geschlossene Registerkarte abzielt

@btoo das ist wahrscheinlich das, was es in einer solchen Welt tun würde. Dies ist jedoch eine sehr radikale Änderung in der Funktionsweise von VS Code.

Ich komme von PHPstorm und das Fehlen von Terminal-Registerkarten ist wirklich frustrierend. Alle Brainstorm-Produkte haben Terminal-Registerkarten. Dies ist eine sehr nützliche Funktion.

In der Tat eine nützliche Funktion, ich würde die Entwickler bitten, sie hinzuzufügen. Dies wird das Leben einfacher machen, wenn wir mehr als zwei Dinge gleichzeitig überwachen müssen. Ich mag die Idee @plmrry wirklich

+1
Registerkarten im Terminal sind UX-freundlicher als Select und nehmen nicht viel Platz ein

+1

Dies ist ein Teil des Grundes, warum ich immer noch iterm und cmder split screen verwende, da ich mehr als einen gleichzeitig sehen kann. Es ist sinnvoll, dass vscode derzeit mehrere gleichzeitig ausführen kann, wodurch die Möglichkeit hinzugefügt wird, beide gleichzeitig anzuzeigen (unabhängig davon, ob sie horizontal geteilt sind oder Registerkarten die Leistung nicht beeinträchtigen sollten).

Wenn es ein Leistungsproblem geben würde, würde vscode auch einfrieren, wenn ich npm run server auf einer Registerkarte und mongod auf einer anderen ausführen würde (oder was auch immer die mehreren Befehle sein mögen, die jemand ausführen muss).

Kleines Update dazu: Ich bin derzeit damit beschäftigt, das Terminal zugänglich zu machen (https://github.com/Microsoft/vscode/issues/8339). Danach wird wahrscheinlich das nächste große Stück, an dem ich arbeiten werde, sein Terminal-Aufteilung (https://github.com/Microsoft/vscode/issues/7504), die von diesem Problem abgezweigt wurde (und wahrscheinlich das ist, was viele der Leute, die dies befürworten, wirklich wollen). Dies steht auf der Roadmap https://github.com/Microsoft/vscode/wiki/Roadmap#terminal

@AnthonyMichaelc Es gibt keine Leistungsprobleme beim jüngsten Verbesserungen superschnell.

(Aufteilen) ist wahrscheinlich das, was viele der Leute, die dies befürworten, wirklich wollen

@ Tyriar Ich habe Tabs hochgestuft, weil ich Tabs will, nicht teilen. Ich vermute, die meisten anderen Leute haben auch gemeint, wofür sie gestimmt haben - ein vertikal oder horizontal schmales Terminal macht das nicht für mich.

... Ich habe gerade all das durchgelesen und kann nicht glauben, dass ich diese Idee verpasst habe:

Fügen Sie der vorhandenen Registerkartenleiste zusätzliche Registerkarten hinzu, wenn neue Terminals geöffnet werden.
Problems | Output | Debug Console | Terminal 1 | Terminal 2 | Terminal 3 ...
... außerdem ist die Debug-Konsole nicht besonders nützlich, wenn Sie den Debugger nicht tatsächlich verwenden.

(und ist wahrscheinlich das, was viele der Leute, die dies befürworten, wirklich wollen)

Ich werde nur dies einfügen .... (erster Beitrag in diesem Thema)

Lassen Sie mich zusätzlich zu
Zum Beispiel möchte ich beim Debuggen eines Servers die Ausgabe eines anderen Dienstes oder den Datei-Watcher beobachten, der meinen Client erstellt, ohne ständig die Ansicht zu wechseln, auch nicht über Tastenkombinationen.
Ich würde Split-Terminals (auch unter Windows;) gerne als Start begrüßen, aber flexible Registerkarten im linken / mittleren / rechten Bereich würden die "Aussichtsplattform" von vscode erheblich verbessern, ohne die Benutzeroberfläche zu überladen.

@PixelT Das erste Bild in dem Beitrag, den Sie zitieren, enthält Tabulatoren, genau wie im Titel angegeben. Vielleicht eine separate PR einreichen und hier zum Teilen verlinken?

@mikemaccana Bitte lesen Sie meinen Beitrag noch einmal mit Verständnis, denn ich sehe, dass Sie ihn nicht verstehen + Ich habe nichts entfernt:]

@PixelT Du hast recht, ich dachte fälschlicherweise, du hättest ein Bild entfernt - sorry. Das heißt: Der Titel und der erste Vorschlag sind eher Tabulatoren als Teilen, und ein separates Problem für das Teilen wäre gut.

@mikemaccana split : https://github.com/Microsoft/vscode/issues/7504

Könnten wir die Option haben, Registerkarten zu haben, diese aber standardmäßig deaktivieren?

Eine Vorschau der Aufteilung ist in Insiders gelandet. Das vollständige Update finden Sie unter https://github.com/Microsoft/vscode/issues/7504#issuecomment -365683609.

Ich denke, das ist definitiv ein Schritt in die richtige Richtung. Ich bin sicher, jemand wird sich beschweren, warum ich nicht 15 Terminals einbauen kann, aber für mich das und wäre großartig. Wenn ich an so etwas wie einem mittleren Stapel arbeite, kann ich ein doppeltes Terminal nur für den Nodemon und die Mongos usw. haben und dann ein anderes Terminalpaar öffnen, um den ng-Aufschlag auszuführen und Befehle zu generieren.

Wenn nun die stabile vscode-Version diese Option hätte und die andere Funktionsanforderung, ein Rasterlayout zu haben, auf das ich alle Träume gewartet habe, würde wahr werden, haha.

Randnotiz: Ich bemerkte nur, dass ich einige Minuten lang verwendet hatte, wenn ich versuchte, opt / alt + cmd / ctrl schnell hin und her zu wechseln. Der Fokus schien etwas dahinter zu liegen. (Kann nur ich sein)

@AnthonyMichaelc

Ich bin sicher, jemand wird sich beschweren, warum ich nicht 15 Terminals einbauen kann, aber für mich das und wäre großartig.

Der Plan ist eigentlich, so viele zuzulassen, wie Sie möchten. Bisher habe ich das Problem jedoch nur für n = 2 gelöst.

Gitterstruktur

Wir diskutieren dies jetzt aktiv, es hat sogar einen Platz im Iterationsplan von Februar https://github.com/Microsoft/vscode/issues/43361

Randnotiz: Ich bemerkte nur, dass ich einige Minuten lang verwendet hatte, wenn ich versuchte, opt / alt + cmd / ctrl schnell hin und her zu wechseln. Der Fokus schien etwas dahinter zu liegen. (Kann nur ich sein)

Ich habe das noch nicht gesehen, aber ich werde nach Langsamkeit Ausschau halten.

@AnthonyMichaelc

Wenn ich an so etwas wie einem mittleren Stapel arbeite, kann ich ein doppeltes Terminal nur für den Nodemon und die Mongos usw. haben und dann ein anderes Terminalpaar öffnen, um den ng-Aufschlag auszuführen und Befehle zu generieren.

Es ist sehr komfortabel, mehrere Terminals und einen Editor gleichzeitig zu haben. In meinem täglichen Leben habe ich das erste Terminal für den Entwicklungsserver, das zweite für Unit-Tests und manchmal das dritte für Git.

Es gibt eine hackige Möglichkeit, dies im cmder-Terminal für Windows zu erreichen, indem Sie VSC als eine der Terminal-Registerkarten öffnen (hier). Ich kann es kaum erwarten, eine native Lösung für Visual Studio Code zu finden, da bei der Verwendung von VSC und Cmder in einige Probleme mit Verknüpfungen auftreten diesen Weg.

@ Tyriar Wie ich sehen kann, handelt es sich bei diesem Topis um Tabs im Terminal, keine Aufteilung ...?

@ PixelT es ist eindeutig verwandt. Viele Leute haben in dieser Ausgabe angegeben, dass sie mehrere Terminals gleichzeitig sehen können, was die Aufteilung vorerst lösen wird, sodass sie es nützlich finden.

Ich kann Ihnen nicht zustimmen - dieses Thema beobachtet und diskutiert hauptsächlich Leute, die Registerkarten im Terminal haben möchten. Zum Aufteilen des Terminals gibt es ein anderes Thema: https://github.com/Microsoft/vscode/issues/7504, das Sie erstellt haben :)

Terminal Tabs & Splitting sind heute in fast jeder modernen IDE Standard.

Zum Testen auf Insider-Build umgestellt , funktioniert erstaunlich, danke

Über Tabs im Terminal passiert immer noch nichts ... 😕

@PixelT Haben Sie die Insider-Version mit Dual-Terminal ausprobiert? Nach dem, was sie gesagt haben, planen sie, es so zu machen, dass Sie so viele Terminals in diesem Layout öffnen können, wie Sie möchten, aber ich glaube, die Insider-Version erlaubt derzeit 2 mit dem Befehl: cmd / ctrl + d Ich glaube

@Morkowski Ich sehe, was Sie getan haben. Ja, ich habe ein Windows und einen OSX-Laptop. Wenn ich also auf dem Windows-Computer bin, verwende ich Cmder so, wenn ich auf dem OSX-Computer iterm verwende und mindestens 2 bis 3 in einem Raster erstelle Layout und 4 bei der Arbeit in einer Mean-Stack-Anwendung.

Hey @Tyriar ein bisschen Feedback - Wenn Sie die Größe der Konsole mithilfe der Schaltflächen Maximize Panel Size oder Restore Panel Size (oder einer Tastenkombination) ändern, wird die Breite der Konsolenfenster vergessen und die Breite jedes Fensters auf den gleichen Betrag zurücksetzen.

Wenn Sie die Größe der Konsole mit der Maus nach oben / unten ändern, werden die Breiten gespeichert.

Ebenso werden Breiten vergessen, wenn die linke Seitenleiste ausgeblendet oder angezeigt wird.

Schließlich werden beim Hinzufügen oder Entfernen eines Fensters die Breiten vergessen - obwohl dies am verständlichsten ist.

Hoffe das hilft!

@jamesjryan Für die ersten https://github.com/Microsoft/vscode/issues/45074 wurde im neuesten Insider ein Problem behoben

Ebenso werden Breiten vergessen, wenn die linke Seitenleiste ausgeblendet oder angezeigt wird.

Ich kann spätestens nicht repro. Bitte erstellen Sie ein Problem, wenn Sie es sehen.

Schließlich werden beim Hinzufügen oder Entfernen eines Fensters die Breiten vergessen - obwohl dies am verständlichsten ist.

Ja das ist wie geplant 🙂

Jemand schreibt hier über Split-Terminal, nicht über Terminal-Registerkarten. Das möchten wir nicht sehen, wenn wir Benachrichtigungen von diesem Ticket erhalten :(

7504

@ Tyriar aktualisiert - funktioniert wie beschrieben, danke!

@KillyMXI Es ist ein Fortschritt in Richtung des

@isidorn Ich frage mich, ob Sie darüber nachgedacht haben, wie wir so etwas anfänglich unterstützen würden. Als ich unmittelbar nach dem Hinzufügen des Terminals Registerkarten in das Terminal einfügte, musste ich zurücksetzen, da alle dagegen waren, Registerkarten in Registerkarten zu haben. Was wäre, wenn wir die Registerkarten der Bedienfeldüberschriften wie folgt gestalten würden:

Ich weiß nicht wirklich, wie ich mit den manchmal großen Titeln umgehen soll, und muss hier Terminal sagen, um sie von den anderen zu unterscheiden. Trotzdem wäre dies mein typisches Setup mit (zwei Registerkarten, von denen eine geteilt ist) und es passt problemlos auf meinen Laptop-Bildschirm, wenn es maximiert ist, auch ohne die anderen Panel-Titel zu verbergen.

Ich denke, das Endspiel gibt dem Benutzer die Flexibilität, Terminals zu platzieren, wo immer sie wollen, aber vielleicht ist dies eine gute Notlösung?

@jamesjryan Ich kann die Lösung des Tyriar nicht als Fortschritt in Richtung der Registerkarten sehen. Sieht für mich völlig orthogonal aus.

Es gibt viele nützliche Dinge, aber sie haben richtige Plätze. Der richtige Ort für das Split-Terminal ist ein anderes Ticket.

Schließlich kehren wir zu den Registerkarten zurück.

Ähnliches wurde oben vorgeschlagen: https://github.com/Microsoft/vscode/issues/10546#issuecomment -359632932
Dies ist die offensichtlichste Sache, wenn Dropdown durch die Liste der Terminals ersetzt wird.

Ich hätte es versucht

• Richten Sie die Anschlusslaschen rechts aus.
• oder fügen Sie eine vertikale Linie vor den Terminals hinzu;
• oder nach rechts ausrichten und eine vertikale Linie anzeigen, wenn sie sich den Elementen auf der linken Seite nähern.

Ich möchte lieber vermeiden, das Wort "Terminal" auf jede Registerkarte zu setzen. Es wird klar genug sein, was es ist.
Oder verwenden Sie das Wort "Terminals:" als eine Art visuelles Trennzeichen.

Problems   Output   Debug Console                  Terminals:  Git   Bash, Bash   +   []   ^

Das ist also eine Art Endergebnis, auf das ich hier hoffen würde:

Entnommen aus https://atom.io/packages/terminal-tab

Es ist einfach und leicht zu verstehen und bietet dem Endbenutzer die Flexibilität, wie er seine IDE aufteilen / strukturieren möchte.

Ich bin verwirrt. Wir können bereits ein Terminal unten, rechts, links oder im Vollbildmodus haben.

Wir können bereits ein Terminal unten, rechts, links oder im Vollbildmodus haben.

Wir tun? Wie erstelle ich ein Terminal auf der linken Seite? Im Moment kann ich nur unten oder rechts sehen.

Sie können nicht links tun, aber trotzdem bin ich durch dieses GIF verwirrt. lol

Ich bin mir nicht sicher über das Atom-Plugin (kann nicht sagen, dass ich es verwendet habe), aber ich würde annehmen, dass Sie mehrere Terminals öffnen könnten, sie würden alle als einzelne Registerkarten behandelt.

Am wichtigsten ist, dass sie sich genauso verhalten wie normale Editor-Registerkarten. Sie können sich an denselben Stellen befinden, an denen Sie Ihren Code haben. Die Web-IDE Cloud9 macht dies sehr ähnlich. Sie können so viele Terminals öffnen, wie Sie möchten, und Sie können sie beliebig auf Ihrem Arbeitsbereich im Layout von Splitscreen + Registerkarten platzieren.

Vielleicht verstehe ich die Besorgnis falsch, aber im Grunde sind die UX-Designer besorgt über die Verwechslung zwischen verschiedenen Arten von Registerkarten.

Ich würde nur die Tab-Leiste standardmäßig ausblenden und 1 "Tab" sichtbar machen. Behalte das Dropdown-Ding.

Wenn ein neues Terminal gestartet wurde und der Benutzer eine Option festgelegt hat, entfernen Sie das Dropdown-Menü und zeigen Sie eine Registerkartenleiste an.

Vermisse ich etwas

Ich denke, es wäre am besten, das Terminal wie andere Editor-Registerkarten zu einer Registerkarte zu machen und den Benutzer einfach entscheiden zu lassen, wie er die Fenster gestalten möchte.

Dies ist, was das "verwirrende" GIF oben zu demonstrieren versucht.

Ja, tut mir leid, wenn das GIF es verwirrender gemacht hat, aber dies ist im Grunde die Prämisse, die ich erreichen wollte.

Ich denke, wenn Sie ein Terminal öffnen, wissen Sie wahrscheinlich, was Sie tun, und es ist überhaupt nicht verwirrend.

Als eine Art Problemumgehung habe ich folgende Tastaturkürzel eingerichtet:

{
  "key": "cmd+right",
  "command": "workbench.action.terminal.focusNext"
}
{
  "key": "cmd+left",
  "command": "workbench.action.terminal.focusPrevious"
}

Damit kann ich schnell zwischen den Terminals wechseln, ohne die Maus und diesen hässlichen Selektor verwenden zu müssen.

@vedmant Sie können das so verfeinern, dass es nur funktioniert, wenn das Terminal fokussiert ist, wenn dies auch vorzuziehen ist:

{
  "key": "cmd+right",
  "command": "workbench.action.terminal.focusNext",
  "when": "terminalFocus"
}
{
  "key": "cmd+left",
  "command": "workbench.action.terminal.focusPrevious",
  "when": "terminalFocus"
}

Es tut mir leid, wenn so etwas bereits vorgeschlagen wurde (ich habe nur die Kommentare überflogen) oder ich sollte dies zu einer neuen Ausgabe machen. Wie auch immer, lass es mich wissen.

Angesichts der Fortschritte, die mit der Ausgabe Nr. 14909 erzielt wurden. Könnten wir eine Option haben, um das Terminal in eine normale Registerkarte zu verschieben, die vom Standpunkt des Standorts aus wie jede andere Registerkarte behandelt wird? Dies würde den Benutzern eine Menge Flexibilität geben, wie sie ihr Terminal anzeigen möchten. Es gibt jetzt (oder eher bald) so viel Flexibilität beim Anzeigen und Anordnen normaler Registerkarten, dass das Terminal jetzt im Vergleich sehr eingeschränkt ist.

@ Tyriar workbench.action.terminal.focusPrevious scheint nicht zu funktionieren

Ich habe auch workbench.action.terminal.focusPreviousPane ausprobiert, da Defaults Kebindings es so verwenden, aber es funktioniert nicht ( workbench.action.terminal.focuNextPane funktioniert auch nicht)

Kurz gesagt: Nur workbench.action.terminal.focusNext funktioniert

    {
        "key": "ctrl+pagedown",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "cmd+pageup",
        "command": "workbench.action.terminal.focusPrevious",
        "when": "terminalFocus"
    }

VSCode-Versionen

Version 1.24.1
Commit 24f62626b222e9a8313213fb64b10d741a326288
Date 2018-06-13T17:47:35.732Z
Shell 1.7.12
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

Betriebssystem: lubuntu 18.04

Ohne Erweiterungen getestet

Bearbeiten

Danke Tyriar, ich habe cmd anstelle von ctrl oben geschrieben

@caub Sie sollten ein neues Problem erstellen, wenn Sie Hilfe

Kürzlich wurde ein Problem mit dem Terminal festgestellt, bei dem es sich befindet: Es macht es unmöglich, die Registerkarte "Probleme" gleichzeitig zu sehen.

Ich denke, Sie haben einen Arbeitsbereich mit mehreren Projekten. Was Sie tun können, ist, ein Terminal pro Projekt zu haben und einen Erweiterungsfokus auf das entsprechende Terminal zu legen, basierend auf der fokussierten Datei im Editor (und auf welches Projekt es gehört).

Es löst Ihr spezielles Problem nicht, erleichtert jedoch das Wechseln und Erkennen von Problemen

Ich bin damit einverstanden, dass die Terminalauswahl wirklich nicht praktikabel ist, es gibt nur Zahlen: 1: bash , 2: bash , .. Es wäre viel besser, den Basisnamen des Ordners anzuzeigen

@caub siehe https://github.com/Microsoft/vscode/issues/29816

Mit etwas mehr Übung wird mir klar, dass dieser Tabs-Vorschlag der beste Weg ist: +1: Derzeit verwende ich immer noch meine eigenen Betriebssystem-Terminals unabhängig von VSCode, da die Auswahl der Terminals dies nicht praktikabel macht, selbst bei besseren Namen wäre es immer noch nicht praktisch genug

Ich denke auch, dass dies gut gelöst werden könnte, wenn das Terminal als Teil des Rasterlayouts leben könnte und aus UX-Sicht viel sinnvoller wäre - wo alles überall aufgenommen werden kann.

@mrmckeb Einverstanden. Ich bin nicht sicher, wie sie sowohl mit Tabs als auch mit Splits umgehen können, aber es ist machbar. Tmux macht es.

Ich hoffe, wir können Terminals auch in den Texteditorfenstern andocken, das wäre schon sehr flexibel.

Ich habe dieses Problem schon seit einiger Zeit beobachtet und hoffe immer noch, dass es umgesetzt wird. Ich sehe, dass ähnliche Themen etwas regelmäßig geöffnet werden. Hoffentlich kann ich noch einmal zusammenfassen, wonach genau gefragt wird und warum (zumindest aus meiner Sicht).

Was

Grundsätzlich hoffe ich, dass ein neues Terminal optional als Editor-Registerkarte erstellt werden kann, um das Verhalten dieser Atom-Erweiterung (das ich seit dem Wechsel von Atom zu VSCode sehr vermisst habe) zu replizieren. Wenn eine neue Terminalregisterkarte erstellt wird, wird sie wie eine Editorregisterkarte behandelt und in eine Editorgruppe eingefügt. Terminal-Registerkarten werden in der Benutzeroberfläche genauso behandelt wie Editor-Registerkarten.

Die Terminal-Registerkarten müssen zum Starten nicht mit den Terminals im Bedienfeld austauschbar sein. Sie könnten zunächst als völlig separate Einheiten erstellt werden, um Feedback zu erhalten.

Warum

Ich lebe praktisch im Terminal, und wenn ich auf diese Weise Terminal-Registerkarten habe, werden alle folgenden Probleme und Anwendungsfälle gelöst:

• Sehen und verwenden Sie mehr als zwei Terminals gleichzeitig. Einfach durch Anordnen von drei oder mehr Terminals, wie ich es im Editor-Raster mag.
• Verwenden Sie VSCode als meinen einzigen Terminalemulator, indem Sie ein VSCode-Fenster mit nur einer Terminalregisterkarte öffnen.
• Habe viele Terminals gleichzeitig geöffnet, aber ich möchte jetzt nicht darauf schauen.

Selbst in einer Welt von Terminal-Registerkarten würde ich die Existenz des Panels im Unterschied zu Editor-Gruppen als nützlich erachten und mich nicht für die Abgabe des Panels einsetzen. Das Panel ist sinnvoll, um zusätzliche Informationen zu platzieren, die sich von den primären Inhalten unterscheiden, mit denen ich arbeite. Der Schlüssel ist, dass ein Terminal für mich normalerweise erstklassiger Inhalt ist, mit dem ich arbeite, und nicht nur zusätzlicher Inhalt. Mit dieser Perspektive ist es für Terminals völlig selbstverständlich, mit Redakteuren zusammen zu leben.

@sagebind Ich sehe den ersten Schritt in diese Richtung darin, Terminal-Registerkarten innerhalb des Panels zu aktivieren und

1. Ermöglichen Sie eine flexiblere Platzierung des Panels. Https://github.com/Microsoft/vscode/issues/57029 , https://github.com/Microsoft/vscode/issues/50984 , https://github.com/Microsoft/ vscode / issue / 37877 , https://github.com/Microsoft/vscode/issues/10121
2. Untersuchen Sie, ob sich einzelne Terminals vom Bedienfeld "lösen" und im Editor-Raster platziert werden können, während Sie sprechen (in dieser Ausgabe nachverfolgt). Dies erfordert ein wenig Arbeit, um die Auswirkungen auf UX, Befehle, Tastenkombinationen und die Erweiterungs-API herauszufinden.

@Sagebind , ich bin

Und wenn Sie ein Old-School-Spieler sind, gibt es ein Dropdown-Menü im Bebenstil (Strg + ~). So bleiben alle meine Bedingungen verborgen, bis es Zeit ist.

Ich denke, diese Erweiterung zeigt, wie Tabs auf saubere Weise erstellt werden.

https://marketplace.visualstudio.com/items?itemName=Tyriar.terminal-tabs

@PauloDanielCarneiro Diese Erweiterung wird tatsächlich von einem der leitenden Entwickler von VSCode selbst (@Tyriar) erstellt.

Ich weiß, dass dieses Problem alt ist, aber das wäre erstaunlich

Dies ist genau die fehlende Funktion, die verhindert, dass alle SysAdmins vollständig von ISE zu VSCode springen.

Als SysAdmin arbeite ich die meiste Zeit gleichzeitig an mehreren Computern.

Ich verbinde mich mit STRG + UMSCHALT + R mit einem Remotecomputer.
Dies öffnet eine neue Terminal-Registerkarte mit dem Computernamen, mit dem ich verbunden bin.
Und jede Terminal-Registerkarte ist mit einer oder mehreren Skript-Registerkarten unten verknüpft.
Ich wechsle mit STRG + R von den Skript-Registerkarten zur Terminal-Registerkarte und umgekehrt.

Das ist so einfach, praktisch und leistungsstark zugleich ...

Wird diese Funktion in Betracht gezogen?

Kein Ersatz, aber Sie können cmd-\ , um Ihr Terminal zu teilen

Danke @ Hum4n01d das ist noch besser, wusste nichts davon.

@ Hum4n01d In meinem Fall kann ich das Terminal mit Ctrl+] teilen oder einfach auf das Symbol klicken, um das Terminal in der oberen rechten Ecke des Terminalfensters neben der Option Kill Terminal zu teilen.

Wenn ich nur 2 oder 3 Terminals benötige, halte ich diese Funktion für sehr nützlich (sogar besser als Registerkarten, da ich nicht von einer Registerkarte zu einer anderen wechseln muss, um das Terminal zu sehen).

Nur in dem Fall, in dem ich mehrere Terminals benötige, ist dies möglicherweise keine Lösung, obwohl Registerkarten möglicherweise auch nicht (per se) vorhanden sind. Stattdessen werden Registerkarten + schwebende Fenster (https://github.com/Microsoft/vscode) benötigt / Issues / 10121).

Ich glaube immer noch, dass der beste Ansatz hier der ist, den das Atom-Team gewählt hat, da Terminals mit Code-Registerkarten austauschbar sind. Auf diese Weise können Benutzer den gewünschten Arbeitsbereich modular erstellen.

Registerkarten im Terminalbereich wären cool, aber warum sollten Sie in das investieren, wenn die Zeit aufgewendet werden könnte, damit Code-Registerkarten Terminalinstanzen umschließen können?

Hallo. Ich habe nach einem Problem gesucht, das ich habe, und bin hier gelandet.

Das einzige, was ich tun möchte, ist, ein Terminal als regulären Editor-Tab zu verwenden

Mein 15-Zoll-Laptop-Display ist einfach nicht groß genug, um mit den kleinen Terminals in einem Build-Ausgabebereich herumzuspielen. Es funktioniert gut für Builds, kann aber für die Verwendung mit Terminals ungeeignet sein.

Wenn ich die Größe des Panels so ändere, dass ich dort tatsächlich arbeiten kann, macht es plötzlich keinen Sinn mehr, dass das Popup der Build-Ausgabe sehr groß wird. Und wenn ich es klein mache, damit es für die Build-Ausgabe geeignet ist, ist es für die Terminalarbeit unbrauchbar. Diese UI-Konzepte mischen sich nicht miteinander und das Hinzufügen in der Tab-Leiste führt zu weiterem Wahnsinn.

Und was ist, wenn ich buchstäblich nicht möchte, dass die Arbeit, die ich in einem Terminal mache, Teil eines Panels ist, das bei der Ausführung von Aufgaben zwischen Registerkarten wechselt? Oder dynamisch auf und ab springen? Damit ich jetzt jedes Mal, wenn ich baue, die Registerkarten in einem anderen Registerkartensystem wechsle ? Und dann zurück zu dem Zeug, an dem ich im Terminal gearbeitet habe? Oh, die Lösung ist also, dass wir das Panel aufteilen können ... Dies wird verrückter und Sie haben eine Reproduktion des gleichen UI-Systems, das VSCode bereits hat. Es ergibt keinen Sinn.

Es wäre eine schlechte Idee, das Panel in ein paralleles UI-System mit konkurrierenden Redewendungen zu verwandeln. Verschiedene Leute versuchen dies mit schlechten Hacks und Workarounds in Erweiterungen zu tun. Es wäre also gut, wenn Microsoft die Kontrolle über die Situation übernehmen würde, indem das Problem behoben würde.

@Zyrsha - warum verwenden Sie in diesem Fall VS-Code? Es hört sich so an, als würden Sie mehr Wert darauf legen, das mit Ihrem Betriebssystem gelieferte Terminal mit mehreren Registerkarten direkt zu verwenden. Ehrliche Frage / sehr verwirrter Leser.

BTW vscode ist die erste und einzige IDE, in der ich Terminal verwende. Auf meinem 13 "-Laptop funktioniert es gut für mich. Für andere IDEs wie Eclipse oder Webstorm bin ich sehr glücklich, Awesome WM für schnelle Switch- und Fensterbestellungen zu verwenden.

Ich denke, die Idee, Terminal (oder ein anderes "Fenster") als regulären Tab zu verwenden, ist nett und funktioniert in Eclipse. Aber Terminal hat einen etwas anderen Workflow, zumindest für mich. Ich brauche die Möglichkeit, schnell zum "richtigen" Terminal zu wechseln. Wie andere benutze ich dafür Terminal Tabs :

Das ist leider nicht perfekt wegen Problemen wie diesem. Außerdem verstehe ich nicht, warum in vsc kein ausgeklügeltes Terminal eingebaut sein sollte.

@ Shane-Smith

Das eigentliche Terminal, das mit Ihrem Betriebssystem geliefert wird, mit mehreren Registerkarten.

Nun, die mit Windows gelieferte Konsolenanwendung unterstützt keine Registerkarten AFAIK. Das ist also raus. Und Linux "kommt" nicht mit einem Terminal-Emulator per se (eine Distribution könnte), Sie müssen einen auswählen, den Sie mögen. In diesem Fall scheint es, dass @Zyrsha VS Code mag, wenn er ein wenig verbessert werden kann.

@sagebind

In diesem Fall scheint es, dass @Zyrsha VS Code mag, wenn er ein wenig verbessert werden kann.

Oh, ich stimme zu - das Terminal in VS Code ist fantastisch. Und ich kommentiere dieses Problem, weil ich damit einverstanden bin, dass es Raum für Verbesserungen gibt.

Der Teil, über den ich verwirrt bin, ist, dass die andere Person anscheinend das Terminal verwenden möchte, um alle ihre Dateien zu bearbeiten. Deshalb frage ich mich, warum sie VS-Code verwenden würden, wenn sie den integrierten Code nicht tatsächlich verwenden Datei-Editor überhaupt? Beim erneuten Lesen ihres Kommentars bin ich vielleicht zu Schlussfolgerungen gesprungen und sie möchten nur einige Dateien im Terminal bearbeiten, nicht alle.

Hallo.

Der Teil, über den ich verwirrt bin, ist, dass die andere Person anscheinend das Terminal verwenden möchte, um alle ihre Dateien zu bearbeiten. Deshalb frage ich mich, warum sie VS-Code verwenden würden, wenn sie den integrierten Code nicht tatsächlich verwenden Datei-Editor überhaupt? Beim erneuten Lesen ihres Kommentars bin ich vielleicht zu Schlussfolgerungen gesprungen und sie möchten nur einige Dateien im Terminal bearbeiten, nicht alle.

Nein, sie möchten nur Terminal-Registerkarten wie Editor-Registerkarten haben, genau das, was wir in Cloud9, Atom und einigen anderen Editoren (sogar Vim und Emacs) haben. Für Benutzer von Mac oder Linux ist es selbstverständlich, dass sich oben im Fenster Editoren und unten einige Terminal-Registerkarten befinden.

Sogar Theia-IDE kann mehrere Terminal-Registerkarten haben und basiert auf einigen Teilen von VSCode.

Schauen Sie sich diese Screenshots an und Sie werden verstehen:

https://discourse-cdn-sjc1.com/business5/uploads/trydiscourse4/optimized/2X/a/a6c21ba006e249a65bb0c4c2ecf94296d6daad20_1_666x500.png

https://lh3.googleusercontent.com/eI50dceQrsPJDhqQmM_QMjd4rkORHRRd_Y3rbnD1M6KYbKulXI72PFC-A0y-SDraVJAXhGTFcg=w640-h400-e365

Ok, lassen Sie uns das Warum für einen Moment ignorieren und uns auf das Wie konzentrieren:

Wie würde dies umgesetzt werden? Gibt es einen architektonischen Grund, warum sich Terminals an ihrem aktuellen Standort befinden?

Wäre es auf effiziente Weise möglich, dass ein Plugin Terminals in Registerkarten bereitstellt?

      Ok, let's ignore the why for a moment and focus on the how:

Wie würde dies umgesetzt werden? Gibt es einen architektonischen Grund, warum sich Terminals an ihrem aktuellen Standort befinden?
Wäre es auf effiziente Weise möglich, dass ein Plugin Terminals in Registerkarten bereitstellt?

Auf der architektonischen Seite:

• VSCode verfügt über viele Skript-Registerkarten, die mit einer einzelnen Konsole verknüpft sind (integrierte PowerShell-Konsole). Dies ist sehr gut zum Testen mehrerer Skripts auf einem einzelnen Computer geeignet. Selbst wenn Sie weitere Terminals hinzufügen, bleiben alle Skriptregisterkarten mit derselben integrierten PowerShell-Konsole verknüpft.
  Zu Beginn wurde VSCode von Entwicklern für Entwickler geschrieben.

• ISE wurde auf die entgegengesetzte Weise erstellt: Sie können mehrere Konsolen öffnen und mit jeder Konsole mehrere Skriptregisterkarten verknüpfen (dies ist sehr gut, wenn Sie gleichzeitig auf mehreren Computern arbeiten möchten).
  Wir schreiben und führen gleichzeitig mehrere Skripte auf verschiedenen Computern aus .
  Zu Beginn wurde ISE für SysAdmins entwickelt.

Glücklicherweise funktioniert die ISE-Methode (Skript-Registerkarten, die mit Konsolen-Registerkarten verknüpft sind) auch für Entwickler.
Die aktuelle VSCode-Methode (Konsolenregisterkarten, die mit "einer einzigen" Skriptregisterkarte verknüpft sind) passt jedoch nicht für SysAdmins.
Wenn Sie den Weg nicht umkehren möchten oder können (von mit Konsolen verknüpften Skripten zu mit Skripten verknüpften Konsolen), sollten wir zumindest in der Lage sein, auszuwählen, mit welcher Konsolenregisterkarte wir die einzelnen Skriptregisterkarten verknüpfen möchten ...

Ich weiß nichts über ISE, aber ich möchte auf jeden Fall das Terminal in einer eigenen Registerkarte oder einem eigenen Fenster haben können, anstatt permanent am unteren Bildschirmrand angebracht zu sein. Ich mag es nicht, die Höhe anpassen zu müssen, um von Codedateien zu einem Terminal hin und her zu wechseln.

Auch wenn Terminal-Registerkarten das Problem lösen, dass mehr als ein Terminal aktiv sein soll, ist es aus UX-Sicht immer noch besser, Terminals auf denselben Registerkarten zu haben, die für Dateien verwendet werden. Dadurch wird sichergestellt, dass Sie zwei Standard-Tastenkombinationen zum Wechseln von Registerkarten anstelle von zwei Standard-Tastenkombinationen und zwei für Terminal-Registerkarten haben (ohne die numerischen Tastenkombinationen zum Wechseln zu einer bestimmten Terminal-Registerkarte). Der Workflow zum Aufteilen des Editors mithilfe dieser Registerkarten oder zum Verschieben von Registerkarten in andere VS-Code-Fenster oder was auch immer Sie sonst mit Registerkarten tun können, wäre dann der gleiche und würde eine Standard-UX erstellen. Derzeit haben Sie zwei verschiedene UX-Workflows, und Sie profitieren nicht viel davon, wenn Sie beide haben.

Ich verstehe, warum dies bis zu diesem Zeitpunkt möglicherweise nicht geschehen ist oder warum wir Terminal-Registerkarten als Problemumgehung haben, aber Terminals in Editor-Registerkarten / -Puffern / was auch immer in Emacs, Atom und dergleichen standardmäßig auf der ganzen Linie ausgeführt wird UX-Erfahrung, die ich auch gerne in VS Code sehen würde.

Jetzt, da Nuclide veraltet ist, würde ich gerne zu VS Code wechseln, aber ich möchte wirklich gerne alle Build-Ausgaben auf dem Terminal lesen können - was mit VS Code sehr schwierig ist. Warum muss das Terminal an eine bestimmte Stelle gezwungen und nicht wie alle anderen Registerkarten / Fenster behandelt werden?

Für mich ist das Hauptproblem, dass ich nicht sehen kann, wie viele Terminals ich geöffnet habe, ohne die Maus zu nehmen. Und es gibt keine Möglichkeit zu wissen, in welche Richtung Sie fahren sollten, um zu einem bestimmten Terminal zu gelangen, ohne willkürlich zu radeln. Tabs waren mein erster Gedanke, aber ich nehme an, es gibt andere Möglichkeiten, dieses Problem zu lösen. Sie können beispielsweise optional aktive Terminals in der Explorer-Leiste anzeigen, wobei das aktive Terminal hervorgehoben ist.

Wie würde dies umgesetzt werden?

Für Linux könnten wir es nur als Sonderfall eines allgemeineren Ansatzes implementieren: Führen Sie benutzerdefinierte Befehle aus und geben Sie ihnen eine X-Fenster-ID der neuen Registerkarte. Wir könnten dann xterm … -into $VSCODE_TAB … für das Terminal ausführen, aber auch andere Dinge sehr einfach integrieren. Wäre auch schön, wenn es einen CLI-Befehl gäbe, um nach einer VSCode-Instanz nach Projektverzeichnis zu suchen (standardmäßig das Arbeitsverzeichnis, in dem der Befehl ausgeführt wurde), eine Registerkarte in dieser Instanz zu öffnen und die X-Win-ID auf stdout zu druckenund VSCodes $DISPLAY falls abweichend Alle externen Dienstprogramme können also der GUI von VSCode beitreten.

Edit 2: Ich werde ein neues Ticket für diese Idee eröffnen

Nein !!! Tab machen ui schlecht aussehen ....

@ donnisnoni95

Nein !!! Tab machen ui schlecht aussehen ....

Ich bin sehr optimistisch, dass es einfach sein wird, sie zu deaktivieren und / oder auszublenden.

Konvertieren Sie das Dropdown-Menü einfach in Schaltflächen und gestalten Sie sie wie Registerkarten des Haupteditors.

Um ganz klar zu sein, möchte ich, dass die Registerkarten mit allen anderen Registerkarten (z. B. den Quellcode-Registerkarten) austauschbar sind. Genau wie in Atom.

Um ganz klar zu sein, ich werde entweder die @floydnoel nehmen , da die Anfrage des OP seit 2016 unbemerkt geblieben ist

@kitsirota Es wurde bemerkt und steht auf der diesjährigen Roadmap. Sie wissen, dass dies und ein damit verbundenes Problem bei schwebenden Fenstern die beiden am häufigsten nachgefragten Funktionen sind. Ich bin nicht sicher, wann es gestartet oder abgeschlossen wird, aber vielleicht hat @Tyriar mehr Informationen dazu.

Ich gehe davon aus, dass dies aufgrund der Nachfrage bald Aufmerksamkeit erregen wird, ich möchte es auch wirklich. Auch wie @jaxspades erwähnte, steht es auf der Roadmap.

Ich habe darauf gewartet und vom ersten Tag an schwebende Fenster, an denen ich VSCode verwendet habe. Derzeit verwende ich ConEmu. Es ist einfach nicht praktisch, das aktuell angegriffene und heruntergefallene Terminal zu verwenden.

Nur eine Anmerkung (während Registerkarten unbedingt zu vscode hinzugefügt werden sollten), wenn Sie ConEmu noch verwenden, möchten Sie möglicherweise Windows Terminal ausprobieren.

Ich warte immer noch darauf :)

Ich möchte nur gleichzeitig "Ausgabe" und "Debug-Konsole" sehen.

Ich brauche nicht unbedingt Registerkarten, möchte aber gleichzeitig Probleme und Terminal sehen. Es kann jedoch schwierig sein, sie ohne irgendeine Bezeichnung voneinander zu unterscheiden, und daher ist eine Registerkarte möglicherweise am besten geeignet. Daher denke ich, dass das geteilte Bedienfeld für das Terminal entfernt werden sollte und zusätzliche Registerkarten für alle Bedienfeldtypen (Probleme, Ausgabe, Terminal usw.) zulässig sind. Obwohl ich nicht wirklich sehen kann, wie viele Registerkarten "Ausgabe" oder "Problem" benötigt werden Die Daten wären identisch. Wenn also beim Hinzufügen eines neuen Tabs und beim Auswählen des Typs, den Sie hinzufügen, Probleme bereits geöffnet sind, ist das Hinzufügen eines zweiten Tabs ausgegraut und deaktiviert. Nur das Terminal ist für mehrere zulässig. Wenn Sie in der Statusleiste auf die Anzeige Probleme und Warnungen klicken, wird beim Klicken automatisch eine neue Registerkarte Probleme geöffnet. Wenn diese bereits geöffnet ist, wird sie entfernt.

Obwohl ich nicht wirklich sehen kann, wie viele Registerkarten "Ausgabe" oder "Problem" benötigt würden, da die Daten identisch wären.

• Kreative Mehrbenutzerkonstellationen jenseits der klassischen 1: 1-Zuordnung von Bildschirmen / Tastaturen / Eingabefeldern zu Benutzern.
• Einzelbenutzer, der die zur Problemlösung verwendeten Tools auf mehrere Bildschirme oder Bildschirmbereiche verteilt. In diesem Fall wäre es nützlich, Filtereinstellungen, Bildlaufposition usw. für jedes Problem- / Ausgabefeld unabhängig zu haben.
• Umgehen mit exotischen Fehlern / fehlenden Funktionen in Ihrer Screencasting-Software.

@ Tyriar @ jaxspades sind 1754: +1: und 187: heart: nicht genug? Und 34: Rakete:? Wie viel sollte es sein?

Das ist noch offen?!

Würde es helfen, dies durch Crowdfunding zu finanzieren? Wo lege ich mein Geld hin?

@Bessonov Ich möchte Terminal-Registerkarten, bin aber nicht bei Microsoft, daher habe ich kein Mitspracherecht. Ich möchte sie jedoch als Editor, nicht in diesem winzigen Fenster am unteren Bildschirmrand. Die Version 1.43 wurde gerade mit Search Editors ausgeliefert. Ich hoffe, dass die Terminals bald folgen werden. @ Tyriar , hilft uns die Suche nach Editoren, näher an die Registerkarten / Editoren des Terminals heranzukommen?

Bearbeiten: Hinzufügen eines Links zum Problem "Sucheditoren".

23931

Auch dies steht auf der Roadmap, es wird rechtzeitig geschehen. Sie müssen es mir nicht sagen, ich möchte es wahrscheinlich mehr als alle anderen hier und bin mir bewusst, dass es das zweithäufigste Thema ist. Es ist jedoch keine so triviale Aufgabe, wie es an der Oberfläche erscheinen mag. Wir investieren aktiv in ein flexibles Workbench-Layout:

• Suchen Sie im Panel
• Suche im Editor
• Alle Bedienfeld- und Ansichtsansichten sind austauschbar

All diese Bemühungen tragen dazu bei, wie dieses Problem letztendlich gelöst wird, und blockieren weitgehend die Arbeit am Terminal. Beispielsweise wirft das Design, das wir für das letztere Element in Betracht ziehen, einige sehr wichtige Fragen zur Funktionsweise von Registerkarten im Terminal auf im Gegensatz zu Panel-Ansichten.

Ich möchte sie jedoch als Editor, nicht in diesem winzigen Fenster am unteren Bildschirmrand.

Während ich vor langer Zeit versucht habe, die Konzepte in separate Themen zu unterteilen, behandelt diese Ausgabe jetzt einige Dinge. Registerkarten im Terminalbereich, Terminalregisterkarten im Editor und Terminalregisterkarten können zwischen den beiden verschoben werden.

Danke für die Updates @Tyriar. Das klingt großartig - all diese Probleme zusammen zu lösen, macht sehr viel Sinn. Wenn es Möglichkeiten für Benutzertests gibt, lassen Sie es uns wissen.

Ich bin mir nicht sicher, ob diese Idee erwähnt wurde, obwohl ich die gesamten Kommentare durchgesehen habe:
Wir brauchen (auch) Terminal-Registerkarten nicht wegen des Aussehens, sondern weil derzeit alle Editor-Registerkarten mit demselben Terminal verknüpft sind.

Derzeit muss ich eine neue VS-Code-Konsole öffnen, wenn ich die Ausführung von Editoren in einem anderen Terminal ausgeben möchte.

Die Möglichkeit, ein Editorfenster mit einem anderen Terminal zu verknüpfen, ist besonders nützlich, wenn Sie den Code verschiedener Editorfenster auf verschiedenen Computern ausführen möchten. Mit ISE können Sie dies in derselben Konsole tun.
Derzeit müssen Sie mit VS Code so viele Konsolen öffnen wie Computer, auf denen Sie den Code Ihres Editors ausführen möchten.

@ Tyriar ,
Zusammen mit Ihren Notizen möchte ich auch "Probleme" und ein "Terminal" -Fenster gleichzeitig nebeneinander sehen können. Ich hoffe das ist auch möglich.
Vielen Dank

@ fullenw1 interessante Idee, von der ich noch nichts gehört hatte, danke!

@ggedde Wir diskutieren aktiv, wie dies in UX-Meetings funktionieren würde.

Wenn das Problem

Die Anschlussfelder benötigen eine Überschrift.

Es ist unmöglich zu wissen, welches Panel welcher Pfad ist, wenn Sie mehrere Beobachter haben

@IceSentry Ich hatte ein Problem, aber @Tyriar sagte, es sei ein Duplikat von diesem. Ich nahm an, dass es verwandt war, weil @Tyriar meine

Ich weiß noch nicht, ob jemand darauf hingewiesen hat, aber Terminal-Registerkarten, die in der Benutzeroberfläche mit Editor-Registerkarten austauschbar sind, sowie eine feste Benutzeroberflächenkonsole sind beide Funktionen in der Cloud9-IDE, wenn Sie ein Beispiel dafür wünschen, wie ich Ich würde erwarten, dass dies funktioniert. Sie müssen nicht einmal das alte Terminalfenster entfernen - Sie müssen es nur ausblenden (wie es jetzt ist) und durch ein gewöhnliches "Editor" -Fenster mit Terminal-Registerkarten ersetzen.

Eine weitere nette Sache bei Terminals in Cloud9 war, dass sie eher an (IIRC) tmux-Instanzen als an direkte Terminals angeschlossen waren. Auf diese Weise konnte das Frontend neu skalieren (dh herunterfahren), ohne Terminalprozesse zu verlieren, und eine reibungslose Verbindung zu einem neuen Client herstellen (eine Funktion, die für Cloud-VS-Code-Benutzer sehr nützlich wäre), und sogar Client-Terminalinstanzen mit anderen teilen (Hypervisor) -level) Benutzer.

Es gibt Erweiterungen für das integrierte VS-Code-Terminal. Wenn Sie jedoch nach einer Abstraktion für Terminals suchen, ist es cool, sie in dtach oder abduco zu bündeln.

Terminal-Registerkarten, die in der Benutzeroberfläche mit Editor-Registerkarten austauschbar sind

Das ist einfach genial.

Wir könnten die untere Konsole entfernen und alle ihre Fenster (Probleme, Ausgabe, Debug-Konsole und alle Terminals) in reguläre Editor-Registerkarten verwandeln, die nach Bedarf geöffnet werden können, wobei jeder Fenstertyp ein bestimmtes Symbol hat.

Als Referenz werden die Erweiterungsinformationsseiten, die Benutzeroberfläche für Einstellungen, Tastaturkürzel und wahrscheinlich andere Dinge bereits auf diese Weise als reguläre Editor-Registerkarten mit einem benutzerdefinierten Symbol behandelt.

Auf diese Weise können Benutzer ihre Terminals nach Belieben aufteilen und anordnen, wobei die vorhandenen Funktionen zum Aufteilen und Anordnen von Editor-Registerkarten verwendet werden.

Natürlich sollten Terminals auch nach dem Schließen der jeweiligen Editor-Registerkarte im Hintergrund weiterlaufen, die bei Bedarf wieder geöffnet werden kann. Der zusätzliche Vorschlag, tmux oder dtach zu verwenden, um die Terminalsitzung über VSCode-Neustarts hinweg am Laufen zu halten, ist ebenfalls eine gute Idee, gehört jedoch zu einem anderen Problem.

Mit der neuen Webview-API können wir das wahrscheinlich schon irgendwann machen.
Das bedeutet jedoch, dass Sie die gesamte Handhabung von launch.json selbst schreiben müssen, was nicht ideal ist.

Es hat jedoch den Vorteil, dass es sich nur um eine Editor-Registerkarte handelt, da die Editor-Registerkarte Serialize / Deserialize-Handler enthalten kann.
Somit ist es möglich, dem Terminal das Speicher- und Wiederherstellungsverhalten zu geben. (Speichern Sie die tmux-Sitzungs-ID und fügen Sie sie bei der Wiederherstellung erneut hinzu.)

POC: https://github.com/mmis1000/Vscode-terminal-tab

@ mmis1000 Es ist sicherlich möglich, jetzt mit der Webview-API zu erstellen, aber es fehlen alle Integrationen, Befehle, Funktionen wie Link-Handling, API-Zugriff für Erweiterungen und es wird im Allgemeinen nur wie eine separate Sache agieren.

Die Funktion zum Speichern und Wiederherstellen wird unter https://github.com/microsoft/vscode/issues/20013 verfolgt

@Tyriar Eigentlich habe ich stattdessen eine Terminal -Instanz erzeugt und sie als untergeordnete pty-Instanz verwendet, sodass zumindest Dinge wie die Git-Integration funktionieren (es sieht so aus, als müsste etwas env an das Terminal übergeben werden).

Es stellt sich jedoch heraus, dass der exponierte API-Vscode viel zu begrenzt ist. Es hat nicht nur den untergeordneten pty-Prozess nicht verfügbar gemacht, sondern auch nicht stdio und Terminalfunktionen wie pty resize. Macht es völlig unmöglich, als Pty-Quelle verwendet zu werden. Also war ich gezwungen, die Pty alleine zu spawnen.

POC: https://github.com/mmis1000/Vscode-terminal-tab

Hey @ mmis1000 könntest du vielleicht ein paar Installationsanweisungen hinzufügen, das wäre toll. Würde das wirklich gerne haben.

@ mmis1000 Es ist vom Design her begrenzt, da dies Teil des Kernprodukts sein sollte. Es gibt auch Leistungsprobleme mit dem window.onDidWriteTerminalData -Ereignis, weshalb es im vorgeschlagenen feststeckt. Während diese Art der Erweiterung als vorübergehende Lösung nützlich sein könnte, mache ich mir Sorgen über den potenziellen langen Schwanz der Benutzer, sobald wir Terminals im Editorbereich zum Arbeiten bringen. Ein weiteres Problem, auf das Sie möglicherweise stoßen, ist die Abhängigkeit von Node-Pty, die als Teil von vscode ausgeliefert wird. Dies ist keine öffentliche API, die für den Verbrauch bestimmt ist, und wird Ihre Erweiterung wahrscheinlich in Zukunft beschädigen.

@ Tyriar Als Cloud9-Benutzer (und jetzt immer noch Cloud9-Benutzer).

Es ist ein bisschen hilfreich, einfach einen beliebigen Bildschirmbereich als Terminal zu verwenden und die Sitzung dauerhaft von tmux zu unterstützen.

Ich benutze meistens nur cloud9 als Webterminal, um den VPS zu steuern. (Und dies ist der EINZIGE Grund, warum ich es jetzt noch benutze. Weil vscode wirklich schlecht mit dem Terminal umgegangen ist. Es ist ein großer Schmerz, das Terminal versehentlich zu verlieren und es jedes Mal wieder zu öffnen.)

Cloud9 zeigt immer dasselbe Fenster, denselben Editor, dasselbe Terminal und dieselbe Sitzung an derselben Stelle an, die Sie sehen, bevor Sie gestern den Browser schließen. Wenn die Sitzung nicht gefunden werden kann (möglicherweise wurde der Server neu gestartet), wird mindestens eine neue Sitzung mit derselben Umgebung für Sie erneut geöffnet.

Wenn ich über die Verwendung eines anderen Online-Editor-Dienstes nachdenke (ich meine, im Browser öffnen), erwarte ich, dass dieser diese sofort unterstützt (oder zumindest durch Erweiterung erreichbar ist), da es unwahrscheinlich ist, dass Sie Ihren Browser nicht schließen ( absichtlich oder versehentlich) überhaupt.

(Auch weil cloud9 dies vor Jahren getan hat, daher glaube ich nicht, dass dies ein technisches Problem ist.)

Der bereitgestellte vscode für Terminal-Erlebnisse sieht für mich ehrlich gesagt nicht wirklich nach einem Produkt der neuesten Generation aus.

@ mmis1000 Könnten Sie bitte einige Installationsanweisungen hinzufügen?

Das Repo https://github.com/mmis1000/Vscode-terminal-tab verfügt über einen eigenen Issue-Tracker. Wer das Bedürfnis hat, nach diesem Projekt zu fragen, fragt bitte dort.

Für eine Demonstration darüber, welches Terminal ich auf einem Remote-Ide / Browser-basierten Ide erwarten kann.
Ich würde erwarten, dass es nur die Tab-Position / Terminalsitzung wiederherstellt, wenn ich es gestern schließe.
Anstelle von It will kill the all the important tasks I am running instantly because I accidentally close the the browser / the browser crashed / the computer BSOD .

Dies ist ein weiteres Problem: https://github.com/microsoft/vscode-remote-release/issues/3096 .

@xgdgsc sieht wahrscheinlich aus, ist es aber nicht.

Was ich erwarte, ist, dass Terminal persistent auch auf lokaler vscode-Instanz universell verfügbar ist. (zumindest bis zu dem Punkt, an dem iterm2 dies tut)
Warum muss eine so nützliche Funktion auf die Remoteverbindung beschränkt sein?

Und ich habe die SSH-Verbindung auch nicht aufrechterhalten, ich habe nur einen Terminal-Multiplexer angeschlossen und dort Dinge ausgeführt.

@ mmis1000 wieder, das in https://github.com/microsoft/vscode/issues/20013 verfolgt wird , siehe dort für die neuesten. Versuchen Sie, das Thema beizubehalten, da es eine Menge Leute gibt, die benachrichtigt werden, wenn Sie dieses Problem kommentieren.

Gibt es eine Chance, dies in den folgenden Iterationen zu haben?

Das Öffnen des Terminals als normaler Editor-Tab ist eine wunderbare Idee für mich, und ich brauche das sehr.