So nutze ich mein Windows Terminal – maximale Terminal-Automatisierung mit tmux und einem Custom-Workflow

 (jyn.dev)
23 Punkte von GN⁺ 2025-06-24 | 1 Kommentare | Auf WhatsApp teilen
  • Durch die Kombination von tmux, SSH, nvim sowie leistungsstarken Such- und Automatisierungsskripten wurde ein einzigartiger Workflow umgesetzt, mit dem sich Dateien auf Remote-Servern auch ohne GUI sofort durchsuchen, bearbeiten und durchsuchen lassen
  • Mit nur einer Tastenkombination werden Dateinamen automatisch in mehreren tmux-Fenstern gesucht und direkt geöffnet; auch Dateiwechsel und Buffer-Verwaltung laufen komplett per Shortcut
  • Aus Unzufriedenheit mit der langsamen Geschwindigkeit von VSCode und Konflikten bei Keybindings wurden alle Abläufe direkt in eigenen Skripten integriert
  • Durch die Kombination von Unix-Tools wie regex, perl, tmux und nvim werden Dateipfade und Zeileninformationen automatisch erkannt und geöffnet
  • Die eigene Umsetzung ist zwar sehr komplex, zeigt aber, wie sich die Stärken und die Erweiterbarkeit des Terminals maximal ausreizen lassen

Meine Art, das Terminal zu nutzen

  • Dieser Beitrag teilt die Erfahrung, durch die Kombination von Terminal und Tools eine effiziente Entwicklungsumgebung aufgebaut zu haben
  • Da der Ablauf recht komplex ist und normalerweise ein Video erfordert, wird hier Text mit einem Demo-Video kombiniert (das Ansehen des Videos ist praktisch Pflicht)
  • Einige Schritte im Video (0:11, 0:21, 0:41) sind Momente, in denen viele Leute überrascht fragen: „Geht das wirklich?“

Schritt-für-Schritt-Zusammenfassung des Terminal-Workflows im Video

  • 0:00 : Windows Terminal auf dem Laptop starten
  • 0:02 : Mit dem Shortcut ctrl + shift + 5 einen neuen Terminal-Tab öffnen, sich per ssh mit dem Desktop zu Hause verbinden und sofort tmux starten
  • 0:03 : In tmux die Standard-Shell zsh starten, Prompt anzeigen und die gesamte Konfiguration asynchron laden
  • 0:08 : Mit zoxide per Fuzzy-Suche ein zuletzt verwendetes Verzeichnis finden und dorthin wechseln
  • 0:09 : Mit der Eingabe eines ripgrep-Befehls beginnen; zsh vervollständigt ihn auf Basis der bisherigen Historie automatisch, mit ctrl + f wird er übernommen
  • 0:11 : Mit dem Shortcut ctrl + kf im gesamten tmux-Scrollback nach Dateinamen suchen; die Dateinamen werden blau hervorgehoben
  • 0:12 : Die Taste n wiederholt drücken, um in der Liste der gefundenen Dateien zur gewünschten Datei zu navigieren
  • 0:21 : Mit der Taste o die ausgewählte Datei in der Standard-App (nvim) öffnen; tmux startet sie in einem neuen Fenster (weiterhin auf dem Remote-Server)
  • 0:26 : Mit rust-analyzer versuchen, zwischen mehreren Referenzen im Code zu springen; einige Makros werden nicht erkannt, bei 0:32 klappt der Sprung korrekt
  • 0:38 : Mit ctrl + kh den tmux-Fokus auf das linke Fenster verschieben
  • 0:39 : Erneut n drücken, um im Zustand „copy-mode“ weiter durch die vorherigen Suchergebnisse zu navigieren
  • 0:41 : Mit o diesmal eine andere Datei in der bereits laufenden nvim-Instanz öffnen
  • 0:43 : Mit b die Liste der geöffneten Datei-Buffer anzeigen, zwischen den beiden Dateien hin- und herwechseln und abschließen

Warum dieser Terminal-Workflow entstanden ist

  • VSCode war langsam, besonders mit Vim-Plugin lief es sehr zäh
    • Zwischen Editor, Vim-Plugin, Terminal und Fensterverwaltung kam es häufig zu Konflikten bei den Keybindings, was störend war
    • Auch der Zed-Editor wurde ausprobiert, war damals aber noch unreif, und die Probleme mit Keybinding-Konflikten blieben bestehen
  • Deshalb wurde begonnen, nvim (Neovim) direkt im Terminal zu verwenden, aber
    • der Prozess, über ripgrep gefundene Dateinamen jedes Mal manuell zu kopieren und in den Editor einzufügen, war viel zu umständlich
    • besonders wenn in den ripgrep-Ergebnissen Dateiname und Zeilennummer zusammen auftauchten,
      • entstanden beim Einfügen jedes Mal Syntaxfehler
      • und es musste oft unnötig editiert werden, bevor die Datei überhaupt geöffnet werden konnte
    • es wurde ein Workflow gebraucht, der Dateipfade direkt öffnen kann, ähnlich wie ctrl-click in VSCode
  • Deshalb wurde die gewünschte Funktionalität mit tmux selbst umgesetzt
    • Wenn Leute fragen, warum man tmux benutzt, lautet die Antwort: genau wegen dieser Automatisierung und der Sitzungs-Persistenz
    • Das Terminal ist viel mächtiger, als man denkt, aber mit den Standardfunktionen wird diese Art von Automatisierung kaum sichtbar
    • tmux ist zwar alt, seine Syntax komplex und es gibt Bugs, wurde aber wegen seiner Erweiterbarkeit und Customizing-Möglichkeiten gewählt

Zentrale Umsetzungsdetails

Dateinamensuche im gesamten Scrollback von tmux

  • Pattern-Matching von Dateinamen in tmux copy-mode mit komplexen regulären Ausdrücken
  • Ein eigens erstelltes Regex-Skript (search-regex.sh) hebt Dateipfade, Zeilen und Spalten hervor
  • Beispiel für eine tmux-Konfiguration: 
    bind-key f copy-mode \; send-keys -X search-backward '정규표현식'

Ausgewählte Datei in neuem oder aktuellem Fenster öffnen

  • Per tmux-Shortcut wird eine ausgewählte Datei so geöffnet, dass sie in der Standard-App oder im Editor (z. B. nvim) landet
  • Unterstützung für relative Pfade und Tilde-Expansion inklusive 
    bind-key -T copy-mode-vi o  send-keys -X copy-pipe 'cd #{pane_current_path}; ...'  
bind-key -T copy-mode-vi O  send-keys -X copy-pipe-and-cancel 'tmux send-keys ...'

Datei in einer bereits geöffneten nvim-Instanz öffnen

  • Ein Perl-Skript lässt tmux ein bestimmtes nvim-Pane finden und übermittelt Datei- und Zeileninformationen per direkter Tasteneingabe an dieses Pane
  • Die Syntax file:line:column wird in einen Vim-Befehl umgewandelt und dann automatisch geöffnet

Vorteile und Grenzen dieses Ansatzes

  • Grenzen lokaler Terminal-Funktionen überwinden: freie Dateisuche, Bearbeitung und Navigation auf Remote-Servern per tmux
  • Der gleiche Workflow funktioniert auch dann, wenn der Editor kein Remote-Editing-Protokoll unterstützt
  • Alle Keybindings, Suchen, Dateiwechsel und Buffer-Verwaltung lassen sich vollständig nach den eigenen Vorlieben integrieren
  • Automatisierung ist schneller und einfacher möglich als die Entwicklung eines VSCode-Plugins
  • Die selbstgebauten Skripte sind anfällig und schwer zu warten, daher nur schwer anderen zu empfehlen

Alternative Lösungen

  • Generell empfohlene Kombinationen aus Open Source und Tools:
    • fish + zoxide + fzf: kann Fuzzy-Verzeichnisse, Befehlssuche und Teile des Datei-Such-Workflows ersetzen
    • Die integrierten Funktionen des Editors (Tabs, Fenster, Fuzzy Finder usw.) reichen für die meisten Nutzer bereits aus
    • qf: ermöglicht Dateiauswahl aus Terminalausgaben, lässt sich aber nicht mit interaktiven Tools koppeln; verwendet eine vi-ähnliche CLI
    • e: ein kleines Tool, das file:line-Pfade erkennt (je nach Editor sind separate Skripte nötig)
    • vim --remote, code filename, emacsclient usw. liefern ähnliche Effekte, allerdings ist die Erkennung von file:line unvollständig

Fazit und Erkenntnisse

  • Das Terminal ist deutlich mächtiger, als man denkt; durch direkte Kombination mit Skripten wird Automatisierung möglich, die GUI-Tools nicht bieten
  • Es gibt jedoch praktische Grenzen, etwa Wartbarkeit und in Skripten eingebaute Bugs
  • Wer sich für automatisierte Terminal-Workflows interessiert, fährt realistisch damit, schrittweise eine eigene tmux/nvim/fzf-Umgebung aufzubauen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-24
Hacker-News-Kommentare

  • Ich nutze auch einen ähnlichen Trick. Ich verwende das tmux-Scrollback und pipe tokenisierte Ausgabe in zsh, sodass ich Autovervollständigung für alles nutzen kann, was auf dem tmux-Bildschirm sichtbar ist. Ich habe dazu einen Thread-Post und den gist-Code geteilt. War wirklich sehr nützlich.

  • Ich mag diese Art von Workflow wirklich sehr und feile seit Jahren in ähnlicher Weise iterativ an meinem Setup. Mit der Zeit versuche ich, benutzerdefinierte Schichten so weit wie möglich zu reduzieren, weil der Wartungsaufwand steigt, je mehr Overlays man hat. Das meiste aus dem Beitrag lässt sich auch in einem unveränderten Vim machen (ohne separates tmux), zum Beispiel mit rg --vimgrep restore_tool | vim -c cb - (vim -c cb - ist eine meiner Lieblingsfunktionen in Vim, und ich finde es erstaunlich, wie wenige Leute sie nutzen). Natürlich kann es aufwendig sein, rg jedes Mal erneut auszuführen, deshalb analysiere ich die Ergebnisse oft erst im Terminal und kopiere bei Bedarf die Ausgabe des letzten Befehls mit einem benutzerdefinierten tmux-Kommando nach Vim. Dabei nutze ich manchmal diesen Trick mit Unicode-Zeichen im Prompt oder übergebe es mit tmux saveb - | vim -c cb -.

    • Vor zehn Jahren habe ich meine riesige Vim-Konfiguration für viele Dateien und viele Pakete weggeworfen und vereinfache seitdem immer weiter, indem ich pro Jahr nur etwa 1–2 Zeilen in eine sehr einfache vimrc aufnehme. Die Standardkonfiguration alter Software hat meist einen Grund, und ich würde empfehlen, diesen Grund zuerst zu verstehen, statt sie blind zu ändern.
    • (Du hast gesagt, vim -c cb - sei deine Lieblingsfunktion in Vim — könntest du erklären, was sie macht? Ich habe ls | vim - und ls | vim -c cb - ausprobiert, sehe aber nicht sofort den Unterschied.)
    • Ich frage mich, ob das demselben Zweck dient wie vim -q <(ripgrep --vimgrep restore_tool).

  • Dieses Setup sieht gut aus, weil es tmux, fzf, rg, zoxide und ein sauberes nvim enthält. Falls sie fehlen, würde ich auch atuin, starship, bat, glow, duf, dogdns, viddy, gum/sesh, dust und btop empfehlen. Man findet sie alle in den Awesome-Terminal-XYZ-Listen auf GitHub. atuin ist praktisch unverzichtbar, und ohne zoxide fühlt man sich wie ein Athlet mit schlecht sitzenden Schuhen. Für Terminal-Aufnahmen ist asciinema die bessere Wahl. Früher hätte man so ein Setup einfach „Programmierer“ genannt. Heute braucht man zusätzlich Tools wie VSCode, Zed oder Cursor und muss wissen, welches LLM man wofür einsetzt. Diese Tools sind jetzt nur das neue „Minimum“ und ersetzen die bestehende Umgebung nicht. Selbst wenn man Claude Code oder gptel gut beherrscht, kann man sich damit manchmal immer noch den Baum zerschießen, und Git ohne magit ist für mich undenkbar. Wenn jemand meint, mit einem unveränderten Cursor schneller zu sein als der OP, sollte die Person einfach mal ein Video aufnehmen, wie sie LLMs tatsächlich in der Praxis einsetzt.

    • Ein Programmierer zu sein bedeutet nicht, dass es nur um das Einrichten der Entwicklungsumgebung geht. Manche berühmten Programmierer benutzen gern den Editor ex, und manche Anfänger haben zwar eine schicke IDE, aber es fehlt ihnen an grundlegendem Verständnis. Gute Tools können natürlich helfen, aber ihr Einfluss auf den tatsächlichen Erfolg war meist gering. LLMs könnten das ändern. Selbst wenn schlecht sitzende Laufschuhe dich 5 % langsamer machen, sind das in einem Startup nicht die feinen Unterschiede, die über Erfolg oder Scheitern entscheiden. Die Ursachen sind meist größere Probleme wie Streit unter Mitgründern, Motivationsverlust oder mangelnder Product-Market-Fit.
    • Deine Tool-Liste ist gut, aber für jemanden, der die meisten Namen wie atuin, dogdns oder btop nicht kennt, kann das ziemlich fremd wirken.
    • Ich liebe diese Befehlsliste. Ich würde hier auf jeden Fall noch fd (von sharkdp) hinzufügen. Das ist ein Ersatz für find und in Sachen Nutzbarkeit hervorragend. Und atuin war in meinem CLI-Leben das größte Upgrade überhaupt. Damit finde ich auch seltene Befehle von vor sechs Monaten extrem leicht wieder.
    • Du scheinst zu sehr auf die Tool-Auswahl fixiert zu sein. Wirklich gute Entwickler liefern auch in einer nackten Umgebung schnell Ergebnisse. Gute Tools können im Detail ein wenig helfen, aber meistens geht es um den eigenen Spaß und Geschmack. Wenn du wirklich spürst, wie stark deine Produktivität von einer IDE abhängt, bedeutet das wahrscheinlich, dass du noch einen langen Lern- und Wachstumsweg vor dir hast. Schon früher galt nicht: „Tools zu kennen = Programmierer zu sein“. Die besten Entwickler, die ich erlebt habe, haben meist mit kaum mehr als more/grep/vi und etwas Nachdenken überragende Ergebnisse geliefert. Wertschöpfung kommt letztlich aus dem Denken. Das gilt sogar im Zeitalter der LLMs.

  • Alle Vim/tmux-Nutzer haben sich mit hoher Wahrscheinlichkeit halb aus Versehen ein inoffizielles „Emacs-Imitat“ gebaut, das zwar buggy, aber schnell ist.

    • Ich habe sogar einen Terminal-Emulator gebaut, der das zweistufige tmux-Präfix durch eine einzige mit Ctrl modifizierte Taste für alle Befehle ersetzt. Projektlink
    • Ich nutze wie du sowohl vim/tmux als auch emacs (und habe früher lange nur emacs verwendet), und meine emacs-Umgebung war viel improvisierter, schlechter dokumentiert und fehleranfälliger. Das vim+tmux-Setup ist im Vergleich stabiler.
    • Dem stimme ich voll zu. In meinem aktuellen Workflow starte ich :Term innerhalb von nvim.
    • Die vim+tmux-Umgebung stützt sich stark auf Systemprimitiven wie Pipes, Dateien, Signale und Scrollback. Dadurch funktioniert das Tooling in verschiedensten Umgebungen sowie über SSH oder in eingeschränkten Shells ganz natürlich und transparent. Das ist ein großer Vorteil für Portabilität und Debugging. Dadurch fühlt es sich an, als könnte mein Workflow auf Basis dieser grundlegenden Garantien frei in Teile zerfallen, weshalb sich eine selbstgebaute Vim-Konfiguration sehr selbstverständlich anfühlt.

  • Er sagt, dass er tmux unter Windows benutzt, und ich frage mich, wie das in der Praxis funktioniert. Es wäre gut, wenn das jemand erklären könnte.

    • Ich vermute, dass er sich per Remote-Zugriff mit einem Unix-System verbindet und dort die eigentliche Arbeit macht. Auf einem Unix-Server kann man tmux problemlos vollständig nutzen. Ich verbinde mich manchmal per SSH mit einer VirtualBox-VM und habe damit eine sauberere Kompatibilitätsschicht als mit WSL. Das ist auch einer der Gründe, warum tmux gegenüber anderen Ansätzen so stark ist. Wenn es auf dem Server installiert ist, erfüllt es auch remote seinen eigentlichen Zweck vollständig. Erklärung dazu

  • Ich mag diese Art, Workflows zu teilen, wirklich sehr. Sie passt perfekt zur Zielgruppe. Ich hätte mir Ton im Video gewünscht, aber die Aktionsliste später zu lesen war auch okay. Ich habe daraus etwas für meinen eigenen Workflow mitgenommen. Es wurden die kryptischen Tastenkürzel von tmux erwähnt — benutzt hier jemand byobu? byobu ist ein Wrapper für tmux, der die meisten Befehle auf F#-Tasten legt. Ich habe es vor zehn Jahren kennengelernt und nutze es seitdem durchgehend. Davor habe ich ein paar Jahre lang reines tmux verwendet.

    • Freut mich, dass dir der Inhalt gefallen hat :) Ich habe versucht, ihn so klar und gut erfassbar wie möglich zu machen. Ich habe die meisten tmux-Shortcuts bei mir umbelegt. ctrl-k ist mein Präfix, und h ist nicht die Standardeinstellung für „linkes Panel auswählen“. byobu habe ich nie benutzt, aber der Beschreibung nach scheint es hauptsächlich bequemere Standard-Shortcuts zu bieten, und dafür würde ich nicht unbedingt noch eine weitere Schicht darüberlegen wollen.

  • Solche Dinge lassen sich auch mit tmux-Plugins umsetzen, ohne direkt riesige Regexe von Hand zu bauen, etwa zur Erweiterung des Copy-Mode. Es gibt tmux-fpp, tmux-copycat, tmux-fingers und tmux-urlview. Es kann für die Geschwindigkeit besser sein, sich so weit wie möglich auf eingebaute Funktionen zu stützen. Ich mag besonders auch tmux-resurrect (Sitzungen speichern/wiederherstellen), tmux-continuum (Automatisierung) und tmux-zen für Oh-My-Fish. Hier sind tmux-resurrect, tmux-continuum und tmux-zen. Ich möchte betonen, dass ein großartiges tmux-Setup tatsächlich überraschend einfach einzurichten ist.

    • Ich habe die ursprüngliche Regex auch aus tmux-copycat übernommen. Aber a) diese Regex erfasst : nicht besonders gut, und b) copycat verwendet eine eigene Viewer-Abstraktion, wodurch man pro Suche nur genau eine Aktion ausführen kann. Mein Ansatz nutzt die eingebaute tmux-Suche wieder, sodass ich beliebige Aktionen an hervorgehobene Dateien binden kann. Der Grund, warum die meisten Plugins nur Kopieren/Einfügen unterstützen oder einen eigenen Modus darüberlegen, ist, dass tmux die Highlight-Steuerung fast nur über die eingebaute Suche erlaubt.

  • So ein Setup ist wirklich wunderschön. Aber es ist immer noch rätselhaft, dass es noch kein richtiges AI-Typeahead im Terminal gibt. Cursor-Tab würde perfekt passen, aber auf das Terminal scheint es nicht angewendet zu werden. Ich habe schon Lust, als Zwischenlösung schnell ein Produkt zu bauen, das Terminal-Ausgaben in eine Fake-Datei pipet und an Cursor weiterreicht.

  • Der Titel des Artikels ist eigentlich „How I use my terminal“.

    • Die automatische Funktion von HN schneidet den ersten Titelbegriff ab, wenn er How ist. Eine echte Begründung gibt es dafür nicht; ein Admin erklärt es zwar als Maßnahme gegen Clickbait, aber in der Praxis stiftet es nur Verwirrung.
    • Zuerst dachte ich, der Artikel sei vielleicht eine Parodie auf den Film „There Will Be Blood“ (weil der aktuelle Titel „I use my terminal“ lautet).
    • Ich dachte auch erst, es sei ein Erfahrungsbericht über einen selbstgebauten Terminal-Emulator.
    • Jetzt weiß ich das auch. Beim Überfliegen des Artikels schätze ich, dass der vollständige Titel ungefähr „I use my terminal (and so should you)“ ist. Artikel über Terminals sehe ich immer gern, und als Chromebook-Nutzer haben mir Browser und Terminal immer gereicht. Wenn ich auf den Mac wechsle, wird es mir zu ausufernd, deshalb nutze ich im Alltag fast nur Terminal oder Browser.
    • Bei der Titelerfassung auf HN werden gängige Präfixe oder Suffixe normalerweise automatisch abgeschnitten.