Das Terminal ist das letzte Werkzeug, das jemand neu entwirft

Alle paar Jahre wird der Editor neu gebaut, der Browser neu gebaut, das Build-System neu gebaut, und das Terminal bleibt, wo es immer war: das älteste Fenster auf dem Bildschirm, geöffnet bei der ersten Anmeldung und seither kaum noch einmal überdacht. Das liegt nicht daran, dass an ihm nichts zu reparieren wäre. Es liegt daran, dass der einfache, fortlaufend scrollende Textpuffer so selbstverständlich geworden ist, dass ihn kaum jemand noch als Entwurfsentscheidung sieht und fast alle für die Form halten, die ein Terminal nun einmal hat. Hier setzt der Gegenentwurf an: Der Puffer ist eine Entscheidung, sie fiel vor Jahrzehnten für Maschinen, die es nicht mehr gibt, und deshalb lässt sie sich neu treffen.

Ein Befehl, ein Block, beisammen gehalten

Der erste Unterschied ist strukturell und nicht kosmetisch. Statt eines einzigen Stroms, in dem Befehle und Ergebnisse zu einer Textwand verrinnen, bleiben jeder Befehl und die Ausgabe, die er erzeugt hat, als ein Block zusammen. Ein Block lässt sich zu einer Zeile zusammenklappen, als Ganzes kopieren oder für sich erneut ausführen, und das Zurückgehen durch eine Sitzung wird zum Springen zwischen Blöcken statt zum Scrollen und Anstarren von Eingabezeichen, um herauszufinden, wo das eine aufgehört und das nächste begonnen hat. Wer je zehn Minuten in einem lauten Build-Protokoll nach oben gescrollt ist, um die Zeile zu finden, an der der Fehler begann, weiß, was das wert ist, und weiß auch, dass die Antwort keine schönere Schrifttype ist.

Vervollständigung, die die Zeile liest, nicht nur den Anfang

Die Vervollständigung einer klassischen Shell vergleicht einen Wortanfang mit einer Namensliste. Sie weiß, was existiert, nicht, was man vorhat. Hier stammt der Vorschlag aus dem Zusammenhang der ganzen Zeile, sodass ein halb getippter Befehl zu der Form ergänzt werden kann, die zu den bereits gegebenen Argumenten passt, und ein unbekannter Befehl nicht nur verlängert, sondern erklärt werden kann. Am größten ist der Nutzen für alle, die eine Umgebung noch lernen: Die Lücke zwischen dem Wissen, dass ein Werkzeug existiert, und dem Wissen, wie man es aufruft, kostet nicht mehr jedes Mal eine Suche in der Dokumentation. Die Suche im Verlauf arbeitet genauso, über Stichwörter durch vergangene Sitzungen statt durch vierzigfaches Drücken einer Pfeiltaste.

Den Befehl bearbeiten, als wäre er Code

Tippen an einer klassischen Eingabeaufforderung ist eine Angelegenheit von einer Zeile: Der Cursor steht am Ende, und alles, was geändert werden soll, muss zurückgelaufen werden. Hier ist die Befehlszeile ein Textfeld mit einem Editor dahinter, also funktionieren Auswahl, mehrere Cursor und die üblichen Tastenkombinationen auf dem, was bereits getippt wurde. Wer den Tag in einem modernen Code-Editor verbringt, verliert damit eine kleine, aber ständige Reibung, weil die Hände nicht mehr zwischen zwei Sätzen von Gewohnheiten wechseln müssen, je nachdem, welches Fenster den Fokus hat. Mit Ergebnissen wird genauso umgegangen: Eine lange Ausgabe lässt sich im Block ansehen und dort bearbeiten, statt sie erst woandershin zu kopieren.

Befehle als etwas, das ein Team behalten kann

Warp Drive ist der Teil mit der weitesten Reichweite. Häufig gebrauchte Befehle, kleine Skripte und ganze Abläufe lassen sich als benannte, teilbare Einträge ablegen und im Team weitergeben, sodass eine funktionierende Reihenfolge einmal geschrieben und dann wiederverwendet wird, statt von jeder Person, die sie braucht, aus dem Gedächtnis neu zusammengesetzt zu werden. Die eigentliche Folge ist nicht Bequemlichkeit, sondern Gedächtnis: Ein Terminal, das festhält, was ein Team gelernt hat, ist nicht mehr rein persönlich, und das Wissen, das sonst in der Shell-Historie einer einzigen Person lebt, wird zu etwas, das der Gruppe gehört. Die Einarbeitung einer neuen Kollegin sieht anders aus, wenn die üblichen Abläufe schon da sind, ausgeschrieben, an der Stelle, an der sie tatsächlich ausgeführt werden.

Rust darunter, und eine GPU, die den Text zeichnet

Zwei Entscheidungen in der Umsetzung erklären einen großen Teil des Gefühls. Die Anwendung ist in Rust geschrieben, einer Sprache, die branchenweit für Geschwindigkeit und Speichersicherheit gewählt wird, was hier zählt, weil die Aufgabe eines Terminals darin besteht, reaktionsfähig zu bleiben, während etwas anderes es mit Ausgabe überschwemmt. Die Oberfläche wird über die GPU gezeichnet, sodass Scrollen, Neuzeichnen und das Setzen dichter Inhalte von Hardware erledigt werden, die genau dafür gebaut ist, im Gegensatz zu Terminals, die den Prozessor bitten, den Bildschirm neu zu malen. In einer ruhigen Sitzung ist der Unterschied unsichtbar. Er wird offensichtlich in dem Moment, in dem eine Testsuite tausende Zeilen ausgibt oder eine Protokolldatei ohne Filter geöffnet wird und das Bild hinterherkommen muss.

Was es weiterhin von dir verlangt

Nichts davon kommt ohne Preis. Die Plattformabdeckung ist schmaler als bei einem Terminal, das seit Jahrzehnten mit jedem Unix ausgeliefert wird: macOS und Linux sind der unterstützte Boden, und wer über andere Systeme hinweg arbeitet, sollte prüfen, bevor er seine täglichen Gewohnheiten hierher verlegt. Stark angepasste Shell-Umgebungen sind die zweite Stelle, an der Reibung auftritt, denn eine über Jahre um ein bestimmtes Prompt-Framework herum gebaute Konfiguration lässt sich womöglich nicht unverändert übernehmen. Der dritte Preis ist der am wenigsten sichtbare und der realste: Das Interaktionsmodell ist anders genug, dass langjährige Terminalnutzer ein paar Tage brauchen, bis die Finger aufhören, nach Gewohnheiten zu greifen, die nicht mehr gelten. Das als Nachteil aufzulisten ist seltsam, aber das Gegenteil zu behaupten wäre unehrlich.

Ob sich der Tausch lohnt

Ein Terminal wird häufiger benutzt als fast alles andere auf dem Rechner eines Entwicklers und seltener überdacht als alles andere, und genau diese Kombination macht einen Neuentwurf zu etwas, das man an seinen eigenen Gründen prüfen sollte, statt es als Verzierung abzutun. Strukturierte Blöcke, kontextbewusste Vervollständigung, Textbehandlung auf Editorniveau und ein gemeinsamer Speicher für Teamabläufe lösen jeweils ein Problem, das heute durch Scrollen, durch Suchen in der Dokumentation oder durch Fragen an die Person gelöst wird, die das Skript geschrieben hat. Wer ganz in einer vertrauten Shell und einer Handvoll Befehlen lebt, gewinnt wenig und ärgert sich vielleicht über das Umlernen. Wer lange Ausgaben liest, mit anderen an denselben Abläufen arbeitet oder die Befehlszeile noch lernt, merkt den Unterschied am ersten Nachmittag. Die ehrliche Zusammenfassung: Das ist keine bessere Version des Terminals, das alle schon haben, sondern die Behauptung, dass eines fällig war, und diese Behauptung ist stark genug, um eine Woche der eigenen Arbeit dagegen zu halten.