Ich benutze Vim seit vielen Jahren auf Linux-Systemen. Auch auf unzähligen Produktivsystemen.

Nicht, weil ich nie herausgefunden hätte, wie man Vim beendet.

Sondern weil es schlicht produktiv ist.

Wenn ich eine Konfigurationsdatei ändern, ein Skript reparieren oder per SSH schnell etwas nachsehen möchte, ergab es für mich nie besonders viel Sinn, dafür eine komplette grafische Entwicklungsumgebung zu starten. Vim ist sofort da, existiert praktisch überall und funktioniert im lokalen Terminal genauso wie auf einer Serverkonsole oder über eine SSH-Verbindung.

Aber es gab immer eine ziemlich eindeutige Grenze.

Für ernsthafte Anwendungsentwicklung kehrte ich zu den IDEs von JetBrains zurück. Insbesondere PhpStorm bietet mir hervorragende PHP-Unterstützung, Refactoring, Projektnavigation, Debugging, Git-Integration, Datenbankwerkzeuge und eine enorme Menge an kontextbezogenen Informationen.

Klassisches Vim konnte dieselben Dateien bearbeiten. Mit dieser Erfahrung konnte es realistisch nicht konkurrieren.

Über mehr als ein Jahrzehnt hinweg habe ich die Idee einer umfassenderen Entwicklungsumgebung im Terminal immer wieder aufgegriffen. Die Antwort fiel jedes Mal ungefähr gleich aus: technisch machbar – sofern ich bereit war, genug Zeit in das Zusammenstecken von Plugins, das Auswendiglernen obskurer Befehle und das Akzeptieren diverser Kompromisse zu investieren.

Diesmal war es anders.

Nachdem ich mein aktuelles Setup eine Weile für echte Entwicklungsarbeit verwendet habe, deckt es inzwischen vielleicht 95 % meines normalen Entwicklungsalltags ab. Nicht 95 % jeder exotischen Funktion, die PhpStorm irgendwo bereithält, sondern ungefähr 95 % dessen, was ich an einem gewöhnlichen Tag tatsächlich brauche.

Dazu gehören größere PHP-Projekte, JavaScript und SCSS, Ansible, Shell-Skripte, Python-Helfer, Markdown, Konfigurationsdateien, Git-Arbeit, Datenbanken und das übliche Linux-Plumbing drumherum.

Ich habe meine IDE nicht ersetzt.

Ich habe die Annahme ersetzt, dass ich jedes Mal eine starten muss, sobald ich programmieren möchte.

Der Terminal-Stack ist endlich erwachsen geworden

Das Interessante daran ist nicht irgendein einzelnes Neovim-Plugin.

Mehrere Ebenen sind ungefähr zur selben Zeit erwachsen geworden.

Neovim entwickelte Vim zu einer erheblich besseren programmierbaren Editor-Plattform weiter. Das Language Server Protocol setzte sich breit durch. Tree-sitter ermöglicht ein strukturelles Verständnis von Quellcode. Moderne Completion Engines wurden schnell und ausgereift. Und Plugin-Manager verloren einen beträchtlichen Teil ihres früheren Schmerzes.

Gleichzeitig hat sich das Ökosystem um das Terminal herum mindestens ebenso stark verändert.

Werkzeuge wie ripgrep, fd und fzf machen die Suche durch riesige Verzeichnisstrukturen faktisch augenblicklich. Neue Terminal-UIs in Rust und Go sehen nicht mehr wie glorifizierte Auswahlmenüs aus, sondern fühlen sich wie richtige Anwendungen an.

Moderne Terminals beherrschen True Color, gutes Unicode und Nerd Fonts. Damit kann ein Terminal-UI sinnvolle Icons, Diagnosen, Git-Symbole, Dateityp-Anzeigen und ansprechende Statusleisten darstellen, ohne in unlesbare ASCII-Kunst zu degenerieren.

Das Ergebnis ist nicht einfach „Vim mit mehr Plugins“.

Es ist eine modulare Entwicklungsplattform.

Mein aktueller Stack sieht grob so aus:

Neovim bildet das Zentrum, soll aber ausdrücklich nicht alles selbst erledigen.

Und genau das erweist sich als wichtig.

AstroNvim: Neovim, ohne erst ein Wochenende lang Neovim bauen zu müssen

Eine nackte Neovim-Installation bleibt relativ minimalistisch.

Natürlich kann man seine Konfiguration vollständig selbst aufbauen – und viele tun genau das. kickstart.nvim ist ein hervorragend dokumentierter Ausgangspunkt, wenn man diesen Weg gehen möchte.

Daneben existieren ausgereifte Distributionen wie LazyVim und NvChad.

Ich habe mich für AstroNvim entschieden.

Nicht, weil ich zuvor sechs Monate lang einen wissenschaftlichen Benchmark sämtlicher Editor-Distributionen durchgeführt hätte. AstroNvim ist populär, aktiv gepflegt, wirkte auf mich kohärent und optisch gelungen, besitzt ein großes Community-Repository für Konfigurationen und erschien mir schlicht als vernünftige Grundlage für eigene Anpassungen.

Das hat sich ziemlich gut bewährt.

AstroNvim ist kein eigener Editor. Es ist eine kuratierte Konfigurations- und Integrationsschicht rund um Neovim.

Der Einstieg ist beinahe enttäuschend einfach

Die erste wichtige Voraussetzung ist ein aktuelles Neovim.

Schnelllebige Neovim-Distributionen orientieren sich meist an aktuellen Neovim-Versionen, während konservative Linux-Distributionen mitunter ältere Pakete ausliefern. Also zunächst prüfen:

nvim --version

Wenn das Paket-Repository aktuell genug ist: wunderbar.

Andernfalls kann man eine der offiziellen Installationsmethoden von Neovim verwenden oder eine stabile Version einfach selbst bauen:

git clone https://github.com/neovim/neovim
cd neovim

git checkout stable

make CMAKE_BUILD_TYPE=RelWithDebInfo
sudo make install

Danach bringt einen bereits das AstroNvim-Template erstaunlich weit:

git clone --depth 1 \
    https://github.com/AstroNvim/template \
    ~/.config/nvim

rm -rf ~/.config/nvim/.git

nvim

Neovim starten, und die Umgebung richtet ihre Plugins selbst ein.

Das ist bereits eine fundamental andere Erfahrung als das alte Klischee, ein komplettes Wochenende damit zu verbringen, eine .vimrc heranzuzüchten.

AstroNvim integriert heute Dinge wie Fuzzy Finding, Completion, Git-Indikatoren, einen Projektbaum, Treesitter, native LSP-Unterstützung und Debugging-Infrastruktur. AstroCommunity ergänzt wiederverwendbare Konfigurationen für Sprachen und Workflows.

Ein Sprachpaket kann ungefähr so unspektakulär aussehen:

return {
  "AstroNvim/astrocommunity",

  { import = "astrocommunity.pack.php" },
}

Von dort aus habe ich die Sprachen und Werkzeuge hinzugefügt, die ich tatsächlich benutze, statt vorsorglich das gesamte beobachtbare Software-Ökosystem einzuschalten.

Mein Setup deckt PHP/Twig, JavaScript und TypeScript, HTML, CSS/SCSS, JSON, YAML/Ansible, Python, Bash, Go, Lua und Markdown ab.

Entscheidend ist: Ich musste nicht für jede dieser Sprachen einzeln eine IDE entwerfen.

PHP war der Test, auf den es wirklich ankam

Syntax-Highlighting für ein Bash-Skript ist nett.

Es beweist nur nicht besonders viel.

Bei PHP erwartete ich, dass der Unterschied zwischen einem Editor und einer echten IDE schmerzhaft offensichtlich werden würde.

Ich arbeite mit größeren Composer-Anwendungen, Objekthierarchien, Service-Layern, Framework-Code, Vendor-Abhängigkeiten und genügend Typinformationen, dass einfache textbasierte Autovervollständigung nicht besonders hilfreich wäre.

Dafür verwende ich PHPActor als PHP Language Server.

Und an dieser Stelle wurde die Sache überraschend ernst.

Nehmen wir etwas völlig Alltägliches:

final class InvoiceController
{
    public function create(InvoiceService $invoiceService): Response
    {
        $invoice = $invoiceService->generate(
            $customer,
            $amount,
            true,
        );

        // ...
    }
}

In meinem aktuellen Setup bekomme ich:

• Vervollständigung von Klassen und Methoden;
• Verständnis für Composer und das Projekt;
• automatische use-Imports;
• Methodensignaturen während des Tippens;
• Anzeige des aktuell aktiven Parameters;
• Inlay Hints für Parameternamen;
• Hover-Informationen;
• Go-to-Definition;
• Referenzen;
• Navigation zu Implementierungen;
• Dokument- und Workspace-Symbole;
• semantisches Umbenennen;
• Code Actions;
• Diagnosen;
• Formatierung;
• Test- und Debugger-Integration.

Wenn ich den Namen einer Klasse zu tippen beginne und den entsprechenden Completion-Vorschlag auswähle, kann der dazugehörige Import einfach automatisch oben in der Datei erscheinen.

use App\Service\InvoiceService;

Das klingt banal, weil jede ernsthafte grafische IDE das seit Ewigkeiten beherrscht.

Genau deshalb ist es relevant.

Das ist kein cleverer Vim-Trick mehr. Das ist gewöhnliche IDE-Funktionalität in einem Terminal-Editor.

Kleine Verfeinerungen machen einen großen Unterschied

AstroNvim verwendet derzeit blink.cmp für Completion. Automatische Signaturinformationen zu aktivieren, erfordert nur eine kleine Konfigurationsanpassung:

return {
  {
    "saghen/blink.cmp",
    opts = {
      completion = {
        documentation = {
          auto_show = true,
          auto_show_delay_ms = 250,
        },

        ghost_text = {
          enabled = true,
        },
      },

      signature = {
        enabled = true,

        trigger = {
          enabled = true,
          show_on_trigger_character = true,
          show_on_insert_on_trigger_character = true,
        },

        window = {
          show_documentation = true,
        },
      },
    },
  },
}

Wenn ich nun Folgendes tippe:

$invoiceService->generate(

kann unmittelbar etwas in dieser Art erscheinen:

generate(Customer $customer, Money $amount, bool $send = false): Invoice
         ^^^^^^^^^^^^^^^^^^

Während ich weiter tippe, wandert die Markierung zum jeweils aktiven Parameter.

PHPActor kann zusätzlich Parameter-Inlay-Hints liefern:

phpactor = {
  init_options = {
    ["language_server_worse_reflection.inlay_hints.enable"] = true,
    ["language_server_worse_reflection.inlay_hints.params"] = true,
    ["language_server_worse_reflection.inlay_hints.types"] = false,
  },
}

Einige Informationen lasse ich bewusst deaktiviert. Eine IDE kann genauso nervig werden wie ein Terminal, wenn jede theoretisch verfügbare Annotation permanent nach Aufmerksamkeit schreit.

Es geht nicht um maximale Informationsdichte.

Es geht darum, genau die Informationen verfügbar zu haben, die ich in diesem Moment brauche.

Große Projekte fühlen sich nicht groß an, wenn Navigation augenblicklich ist

Einer meiner liebsten Aspekte des Setups klingt beinahe langweilig: Dinge finden.

In meiner Konfiguration ist <Space> der Leader-Key. Einige der Mappings, die ich ständig benutze, sind:

<Space>ff    Datei finden
<Space>fw    Projekttext durchsuchen
<Space>fb    offene Buffer

gd           zur Definition springen
grr          Referenzen finden

<Space>lS    Symbole / Struktur
<Space>la    Code Actions

<Space>gg    LazyGit

Die exakten Mappings können sich zwischen Konfigurationen und AstroNvim-Versionen selbstverständlich ändern. Entscheidend ist der Workflow.

ff und fw sind extrem schnell.

Ich kann sie auf ein Repository mit Hunderten oder Tausenden Dateien loslassen, und die Ergebnisse erscheinen praktisch unmittelbar.

Diese Geschwindigkeit ist kein Zufall. Das moderne Terminal-Ökosystem kombiniert bevorzugt spezialisierte Werkzeuge, statt deren Funktionen immer wieder neu zu implementieren.

ripgrep ist außergewöhnlich gut darin, Quellcode-Verzeichnisse rekursiv zu durchsuchen und dabei Git-Ignore-Regeln zu respektieren.

fd erfüllt eine ähnliche Rolle für die Dateisystemsuche.

Neovim kann darüber einen ausgereiften interaktiven Picker legen.

Das Resultat fühlt sich wesentlich stärker nach dem „Search Everywhere“ einer IDE an als nach manuellem grep durch ein Projekt – nur eben weiterhin extrem schnell.

Und neben der Textsuche existiert die semantische Navigation.

Wenn ich jedes textuelle Vorkommen von InvoiceService sehen möchte, durchsuche ich das Repository.

Wenn ich dagegen tatsächliche Referenzen auf das Symbol unter meinem Cursor suche, frage ich den Language Server.

Das sind unterschiedliche Operationen. Beide sofort verfügbar zu haben, ist ausgesprochen nützlich.

Dieselbe Umgebung begleitet mich auch in die weniger glamourösen Dateien

PHP ist ein guter Belastungstest. Den größten Reibungsverlust spart mir dieses Setup allerdings an anderer Stelle.

Der größere Vorteil ist die Kontinuität.

Ich kann eine Stunde in einer PHP-Anwendung arbeiten und anschließend Folgendes bearbeiten müssen:

roles/nginx/tasks/main.yml

danach:

scripts/import-data.py

anschließend:

README.md

und schließlich:

/etc/caddy/Caddyfile

Eine vollständige IDE kann all diese Dateien natürlich ebenfalls bearbeiten.

Aber für ein Python-Hilfsskript mit 20 Zeilen, eine Ansible-Rolle oder ein Markdown-Dokument eine schwergewichtige Projektumgebung zu starten oder zu wechseln, fühlt sich schnell überdimensioniert an.

Ein simpler Texteditor geht wiederum zu weit in die andere Richtung.

Modernes Neovim sitzt genau in einem ausgesprochen nützlichen Mittelfeld.

Für YAML und Ansible bekomme ich weiterhin Diagnosen, Completion und strukturelles Verständnis.

Für Python erhalte ich Language-Server-Intelligenz.

Für Go gibt es gopls.

Für TypeScript gibt es vtsls.

Für Bash existieren Language Server und Linter.

Die Benutzeroberfläche bleibt dabei weitgehend dieselbe:

• Vervollständigung
• Definitionen
• Referenzen
• Diagnosen
• Symbole
• Umbenennen
• Code Actions
• Formatierung

Der semantische Unterbau wechselt mit der jeweiligen Sprache.

Das macht Neovim besonders nützlich für Menschen, deren Arbeit Anwendungsentwicklung, Infrastruktur und Betriebssysteme überspannt, statt vollständig innerhalb eines einzelnen Frameworks zu leben.

Außerdem eignet sich die Umgebung als zweite Meinung.

PhpStorm und PHPActor melden nicht zwangsläufig exakt dieselben Dinge. Linter und Language Server setzen an unterschiedlichen Stellen eigene Schwerpunkte. Während mein JetBrains-Setup vielleicht glücklich Rechtschreibfehler in Kommentaren markiert, beschwert sich mein Terminal-Stack möglicherweise über etwas völlig anderes.

Dasselbe Projekt gelegentlich durch unterschiedliche Toolchains laufen zu lassen, bringt deshalb bisweilen Dinge ans Licht, die die jeweils andere Umgebung nicht besonders hervorgehoben hat.

tmux ist der Workspace – kein Zubehör

Neovim bildet das Zentrum meines Coding-Setups.

tmux bildet das Zentrum meines Terminal-Setups.

Ich benutze es seit unzähligen Jahren, weil die grundlegende Idee schlicht sehr gut ist: einen persistenten Terminal-Workspace erzeugen, ihn in die gerade benötigten Prozesse aufteilen, sich davon lösen und später exakt dorthin zurückkehren.

Eine normale Projektsitzung kann beispielsweise so aussehen:

┌─────────────────────────────────┬──────────────────┐
│                                 │                  │
│ Neovim / AstroNvim              │ tail -F app.log  │
│                                 │                  │
│                                 │                  │
├─────────────────────────────────┼──────────────────┤
│ Shell / Tests                   │ btop             │
└─────────────────────────────────┴──────────────────┘

In einem weiteren tmux-Fenster kann Rainfrog für die Datenbankarbeit laufen.

Ein anderes enthält vielleicht einfach nur eine Shell.

Der entscheidende Punkt: Nichts davon muss in Neovim eingebettet werden.

Live-Logs benötigt?

tail -F.

Systemüberwachung?

btop.

Datenbankoberfläche?

Rainfrog öffnen.

tmux setzt die Werkzeuge zu einem gemeinsamen Workspace zusammen.

Wenn meine SSH-Verbindung abbricht, läuft dieser Workspace weiter.

Wenn ich abends aufhöre:

tmux detach

und am nächsten Morgen zurückkehre:

tmux attach

können die Prozesse noch immer exakt dort sitzen, wo ich sie verlassen habe.

Wenn man sich einmal daran gewöhnt hat, ist das erstaunlich schwer wieder aufzugeben.

Workspaces lassen sich trivial automatisieren

tmux ist ebenfalls eine Anwendung mit einem beeindruckenden Handbuch und einer stattlichen Sammlung an Tastenkombinationen.

Es ist aber auch skriptbar.

Schon ein winziger Projekt-Launcher kann etwas Sinnvolles tun:

#!/usr/bin/env bash

set -e

session="${1:-dev}"

tmux new-session \
    -d \
    -s "$session" \
    -c "$PWD" \
    'nvim'

tmux split-window \
    -h \
    -t "$session:0" \
    -c "$PWD" \
    'tail -F var/log/app.log'

tmux new-window \
    -t "$session" \
    -n db \
    -c "$PWD" \
    'rainfrog'

tmux new-window \
    -t "$session" \
    -n monitor \
    'btop'

tmux select-window -t "$session:0"
tmux attach -t "$session"

An das jeweilige Projekt angepasst, erscheint damit mit einem einzigen Befehl ein vollständiger Entwicklungs-Workspace.

Man kann das erheblich weiter treiben.

Man muss aber nicht.

Dieses Muster zieht sich durch den gesamten Stack.

Der Editor ist nur so gut wie das Terminal um ihn herum

Eine hervorragende Neovim-Konfiguration in einer miserablen Shell-Umgebung würde die Hälfte des Sinns verfehlen.

Ich benutze Zsh zusammen mit Oh My Zsh als weitere kuratierte Basis.

Zsh selbst ist extrem leistungsfähig, wirkt ohne Konfiguration aber vergleichsweise nüchtern. Oh My Zsh bietet hier dieselbe Art von Beschleunigung wie AstroNvim für Neovim: Konventionen, Plugins, Completion, Git-Integration, Themes und ein großes bestehendes Ökosystem.

Anschließend verfeinere ich nur noch die Dinge, die mir tatsächlich wichtig sind.

eza ist beispielsweise ein hervorragender moderner Ersatz für ls:

alias ls='eza --icons=auto --group-directories-first'
alias ll='eza -lah --git --icons=auto --group-directories-first'

Mit einem Nerd Font werden scheinbar kosmetische Dinge wie Dateisymbole in der gesamten Umgebung tatsächlich nützlich.

Sie erscheinen in Dateilisten.

Sie erscheinen in Yazi.

Sie erscheinen im Projektbaum von Neovim.

Sie erscheinen in Statuszeilen und Pickern.

Das Terminal wird damit im wörtlichen Sinne zu einer grafischen Umgebung – nur eben zu einer, die aus Zellen statt aus klassischen Desktop-Widgets aufgebaut ist.

Fokussierte Terminal-Anwendungen sind oft besser als noch ein weiteres IDE-Panel

Ein Fehler wäre, jede nur denkbare Entwicklungsfunktion zwanghaft in Neovim hineinpressen zu wollen.

Genau das möchte ich nicht.

Für Git ist LazyGit hervorragend.

Für den normalen Ablauf:

Änderungen prüfen
→ stagen
→ committen
→ pushen

finde ich es häufig schneller als die Navigation durch die entsprechende IDE-Oberfläche.

JetBrains bietet eine erheblich reichhaltigere Git-Umgebung, insbesondere wenn Merges kompliziert werden. Das bleibt wertvoll.

Aber die meisten Commits sind keine komplizierten Merges.

Für Dateien verwende ich Yazi, einen schnellen asynchronen Terminal-Dateimanager in Rust.

Das ist vor allem dann praktisch, wenn eine Aufgabe Assets oder Dateioperationen umfasst, die nicht besonders natürlich in einen Projektbaum innerhalb des Editors passen.

Für Datenbanken bietet mir Rainfrog eine fokussierte Datenbankoberfläche im Terminal.

Für jede SQL-Abfrage brauche ich keine 100 % von DataGrip.

Ich brauche einen brauchbaren Tabellenbrowser, Schemas, Queries und Ergebnisse.

Dahinter steht eine größere Philosophie:

• Code: Neovim
• Git: LazyGit
• Dateisystem: Yazi
• Datenbanken: Rainfrog
• Komposition: tmux
• Shell: Zsh

Jedes Werkzeug darf in genau einer Aufgabe hervorragend sein.

Und weil sie alle im Terminal leben, kostet ihre Kombination fast nichts.

KI hat einen erstaunlich großen Teil der alten Lernsteuer abgeschafft

Es gibt noch einen weiteren Grund dafür, dass ich aus all dem diesmal tatsächlich eine kohärente Umgebung bauen konnte.

KI.

Nicht, weil ein LLM 1.500 Zeilen Lua nach ~/.config/nvim kippen und anschließend den Sieg erklären kann.

Das wäre das Terminal-Äquivalent dazu, eine Produktivplattform per Vibe Coding zusammenzuwerfen und zu hoffen, dass die Tests ohnehin nur Dekoration sind.

Der wesentlich interessantere Einsatzbereich ist technische Übersetzung und interaktives Lernen.

Komplexe Terminal-Werkzeuge hatten historisch ein gewaltiges Discoverability-Problem.

Angenommen, ich weiß, was ich möchte:

Während ich einen PHP-Methodenaufruf tippe, möchte ich die Parameter sehen und den jeweils aktuellen Parameter hervorgehoben bekommen.

Ich muss dabei nicht wissen, dass die entscheidenden Begriffe LSP signature help, trigger characters und blink.cmp signature configuration heißen.

Früher bedeutete das, Dokumentation, Forenbeiträge, GitHub-Issues und Konfigurationsbeispiele zu durchsuchen, bis ich das gewünschte Verhalten in meinem Kopf auf die Terminologie mehrerer unterschiedlicher Projekte abgebildet hatte.

Heute kann ich einfach das gewünschte Verhalten beschreiben.

KI kann dabei helfen, die zuständige Ebene zu identifizieren und daraus eine kleine mögliche Konfiguration abzuleiten.

Ob das Ergebnis sinnvoll ist, entscheide weiterhin ich.

Dasselbe passierte mit automatischen Imports, PHPActor-Inlay-Hints, AstroNvim-Sessions, Neo-tree-Filtern, Aerial, Mason-Provisionierung und zahlreichen anderen kleinen Verfeinerungen.

Noch wichtiger: KI kann mir die Umgebung beibringen, während ich sie benutze

Das ist für mich sogar bedeutender als die Konfiguration selbst.

Vim besitzt eine riesige Befehlssprache.

tmux hat reichlich Befehle und Shortcuts.

AstroNvim fügt Mappings hinzu.

Einzelne Plugins bringen wiederum weitere mit.

Niemand muss zwei Wochen lang mit dem Programmieren aufhören und jedes Handbuch von vorne bis hinten lesen, bevor der Editor überhaupt benutzt werden darf.

Wenn ich beispielsweise wissen möchte:

Wie ersetze ich nur den Text innerhalb dieser Anführungszeichen?

kann ich fragen und bekomme:

ci"

Die aktuellen Klammern?

ci(

Einen vollständigen Block einschließlich geschweifter Klammern löschen?

da{

Den gesamten Inhalt des Buffers löschen?

ggdG

Das sind native Vim-Operationen, keine AstroNvim-Magie.

Und genau hier kann KI noch etwas anderes ausgesprochen Nützliches erklären: Welche Ebene ist überhaupt für dieses Verhalten verantwortlich?

Vielleicht ist der Befehl natives Vim.

Vielleicht stammt er aus Neovim.

Vielleicht ist es ein AstroNvim-Mapping.

Vielleicht stellt PHPActor die Funktion über LSP bereit.

Vielleicht gehört sie zu einem Plugin.

Beim Durchforsten älterer Antworten im Netz geht diese Unterscheidung erstaunlich schnell verloren.

Ich kann die 5 % lernen, die ich heute brauche, sie anschließend regelmäßig benutzen und allmählich in Muskelgedächtnis verwandeln.

Das ist eine wesentlich realistischere Art, eine so tiefgehende Umgebung zu erlernen.

Selbst die Maus ist nicht verboten

Es gibt auch keinen Preis dafür, die eigene Arbeitsumgebung unnötig feindselig zu gestalten.

Ich arbeite stark über die Tastatur. Manchmal ist es aber schlicht praktisch, durch eine Datei zu scrollen, einen Pane anzuklicken oder etwas mit der Maus auszuwählen.

Neovim:

vim.opt.mouse = "a"

tmux:

set -g mouse on

Fertig.

Ein Terminal-Workflow muss nicht zum Vim-Reinheitswettbewerb werden.

Genau hier fühlt sich KI anders an als „Vibe Coding“

Ich benutze KI außerdem, um eine funktionierende Konfiguration anschließend in ordentlichen Deployment-Code zu überführen.

Sobald eine Änderung funktioniert, kann ich beispielsweise fragen:

Verwandle das in eine idempotente Ansible-Task für mehrere Benutzer.

Oder:

Baue dieses tmux-Layout als Shell-Skript.

Oder:

Meine Linux-Distribution nennt fd stattdessen fdfind; passe die Rolle sauber daran an.

Die Maschine besitzt weiterhin eine bewusst entworfene Architektur.

Ich weiß, welche Pakete installiert werden, wo die Binärdateien liegen, welche Language Server aktiviert sind und was die Konfiguration erreichen soll.

KI reduziert lediglich die Zeit, die ich damit verbringe, diese Entscheidungen in mir unbekannte Konfigurations-APIs zu übersetzen.

Das ist etwas fundamental anderes als die blinde Aufforderung: „Bau mir eine Neovim-Konfiguration.“

Meine Entwicklungsumgebung ist Infrastruktur

Ich deploye mein vollständiges Setup tatsächlich über Ansible.

Dazu gehören eine aktuelle Neovim-Installation, die gemeinsam verwendete AstroNvim-Konfiguration, Language-Tooling und mehrere ergänzende Anwendungen.

Eine neue Entwicklungsmaschine erfordert dadurch keine archäologische Expedition durch meine Shell-History.

Provisionieren, Rollen deployen, Neovim starten.

Andere bevorzugen vielleicht Dotfiles, Nix, chezmoi oder ein Bootstrap-Skript für die Shell. Das ist letztlich nebensächlich.

Die wichtige Eigenschaft besteht darin, dass diese gesamte Umgebung aus gewöhnlicher Konfiguration und offenen Werkzeugen besteht. Sie ist reproduzierbar.

Auch Experimente werden dadurch erheblich weniger beängstigend.

Wenn ich meine Editor-Konfiguration bei einem besonders cleveren Experiment zerstöre, weiß ich immerhin exakt, wo meine Source of Truth liegt.

JetBrains gewinnt weiterhin – und das ist völlig in Ordnung

Ich vergleiche dieses Setup bewusst mit JetBrains, weil das ein anspruchsvoller Maßstab ist.

PhpStorm und die IntelliJ-basierten IDEs sind hervorragende professionelle Werkzeuge. Ich benutze sie seit Jahren und suche keinen ideologischen Grund, damit aufzuhören.

Es gibt Situationen, in denen ich die IDE weiterhin bevorzuge.

Komplexes strukturelles Refactoring ist eine davon.

Große Gruppen von Klassen oder Modulen zu verschieben, während die IDE sämtliche betroffenen Referenzen versteht, ist genau die Art von Arbeit, bei der eine vollständig integrierte semantische Umgebung ihre Stärken ausspielt.

Komplizierte Git-Merge-Auflösungen sind ein weiteres Beispiel.

Grafisches Debugging und Profiling können deutlich angenehmer sein.

Interaktive Visualisierungen, spezialisierte Datenbankarbeit, framework-spezifische Werkzeuge und Aufgaben mit vielen visuellen Assets profitieren ebenfalls von einer integrierten GUI.

Und manchmal möchte ich schlicht maximalen Komfort: jeden denkbaren Hinweis, jede Inspection und jede Aktion sichtbar, ohne mich daran erinnern zu müssen, über welchen Mechanismus der darunterliegende Editor sie verfügbar macht.

Auch das hat einen realen Wert.

Der interessantere Vergleich liegt woanders.

Aufgabe	Terminal-Stack	Vollständige IDE
Schneller Config-/Script-Fix	Hervorragend	Meist überdimensioniert
Ansible / YAML / Shell	Hervorragend	Stark abhängig von IDE/Plugins
Normale PHP-Entwicklung	Hervorragend	Hervorragend
Navigation in großen PHP-Anwendungen	Überraschend gut	Hervorragend
Schnelle Datei-/Textsuche	Hervorragend	Hervorragend
Routinemäßiger Git-Commit/Push	Hervorragend	Hervorragend
Großes strukturelles Refactoring	Leistungsfähig	Meist besser
Komplexe Merge-Auflösung	Leistungsfähig	Meist besser
Umfangreiches visuelles Debugging	Leistungsfähig	Besser
Remote-Workflow über SSH	Nativ	Benötigt Remote-Workflow
Gemischte Linux-/Admin-/Dev-Arbeit	Hervorragend	Weniger natürlich
Visuelle Assets / GUI-lastige Arbeit	Schwach	Besser

Das ist kein Wettbewerb, an dessen Ende eine der beiden Seiten verschwinden muss.

Interessant ist vielmehr, wie weit sich die Grenze verschoben hat.

Das Mittelfeld ist plötzlich riesig

Früher existierte eine unangenehme Lücke.

Ein einfacher Texteditor war für viele Programmieraufgaben zu primitiv.

Eine vollständige IDE war dafür wiederum überdimensioniert.

In dieser Lücke steckt überraschend viel echte Arbeit:

• schneller Bugfix
• kleiner PHP-Service
• Ansible-Rolle
• Python-Hilfsskript
• Bash-Werkzeug
• Markdown-Dokument
• Konfigurationsdatei
• normale Feature-Arbeit
• kleine Frontend-Anpassung
• Code Review
• Git-Aufräumarbeiten
• Remote-Debugging

Genau in diesem Bereich glänzt diese Umgebung.

Sie startet sofort.

Sie funktioniert über SSH.

Sie versteht das Projekt.

Sie kann Symbolen durch eine Composer-Codebasis folgen.

Sie kann eine PHP-Klasse automatisch importieren.

Sie kann mir sagen, dass eine Ansible-Task fehlerhaft aufgebaut ist.

Sie kann Tausende Dateien nahezu augenblicklich durchsuchen.

Und sobald ich etwas außerhalb des Editors benötige, gibt mir tmux bereits den Platz dafür.

Für meine eigene Arbeit deckt das inzwischen ungefähr 95 % der Entwicklungssituationen ab, denen ich im Alltag begegne.

Die verbleibenden Prozent enthalten einige tatsächlich schwierige Aufgaben, bei denen eine vollständige IDE ihr Gewicht verdient.

Das erscheint mir als ziemlich gesunde Aufteilung.

Ein kleiner Stack mit einem erstaunlich tiefen Kaninchenbau

Das Amüsante ist, dass sich die Nutzung dieser Umgebung für mich inzwischen ziemlich beiläufig anfühlt.

Darunter passiert allerdings eine ganze Menge:

• Terminal Emulator
• Nerd Font
• Zsh
• Oh My Zsh
• tmux
• Neovim
• AstroNvim
• AstroCommunity
• LSP
• Treesitter
• blink.cmp
• PHPActor
• Mason
• ripgrep
• fd
• fzf
• LazyGit
• Yazi
• Rainfrog
• linters
• formatters
• debug adapters
• Ansible deployment

Das ist zweifellos ein tiefer Stack.

Die eigentliche Leistung des modernen Ökosystems besteht darin, dass er sich im normalen Betrieb nicht mehr danach anfühlt.

Ich kann ein Repository öffnen und arbeiten.

Und wenn ich morgen entscheide, dass sich Funktionssignaturen anders verhalten sollen, dass ich in einem zweiten Pane eine Datenbank-TUI benötige oder für ein bestimmtes Projekt einen eigenen tmux-Bootstrap möchte, handelt es sich meistens um eine kleine, nachvollziehbare Änderung – nicht um die nächste Plattformmigration.

Wenn du in den Kaninchenbau steigen möchtest

Ich würde nicht damit anfangen, das 5.000 Zeilen umfassende Dotfiles-Repository irgendeiner anderen Person zu kopieren.

Installiere ein aktuelles Neovim.

Wähle einen ausgereiften Ausgangspunkt – AstroNvim, LazyVim, NvChad oder kickstart.nvim, je nachdem, wie viel du bereits vorkonfiguriert haben möchtest.

Installiere ripgrep und fd.

Benutze das Ganze in einem echten Repository.

Und ergänze anschließend Funktionen, weil du sie tatsächlich vermisst.

Wenn du viel unter Linux oder auf entfernten Hosts arbeitest, nimm tmux hinzu.

Probiere LazyGit.

Probiere Yazi.

Wenn Datenbanken regelmäßig zu deiner Arbeit gehören, probiere Rainfrog.

Versuche nicht, Vim auswendig zu lernen.

Sobald irgendwo Reibung entsteht, stelle eine sehr konkrete Frage:

Ich befinde mich innerhalb einer PHP-Methode. Wie markiere ich die gesamte Methode?

Was ist das semantische Äquivalent zu „Find Usages“?

Wie springe ich zurück, nachdem ich einer Definition gefolgt bin?

Wie wechsle ich zwischen diesen tmux-Panes?

Wie bringe ich die Completion dazu, den Import automatisch hinzuzufügen?

Lerne genau die Antwort, die du gerade brauchst.

Arbeite weiter.

Eine Woche später ist die Hälfte davon bereits Muskelgedächtnis.

Die IDE ist nicht verschwunden. Ihr Monopol schon.

Ich mag PhpStorm weiterhin.

Ich werde es weiterhin für schwierige Refactorings, komplexes Debugging, grafische Workflows und Projekte benutzen, bei denen die vollständig integrierte Umgebung die Arbeit tatsächlich einfacher macht.

Verändert hat sich lediglich, wie selten ich diese gesamte Maschinerie brauche.

Das moderne Terminal ist nicht mehr nur der Ort, an dem ich mich per SSH auf einen Server verbinde und widerwillig irgendeine Datei bearbeite.

Mit Neovim und AstroNvim im Zentrum, tmux als persistentem Workspace, einer leistungsfähigen Shell darunter und fokussierten Werkzeugen wie LazyGit, Yazi und Rainfrog drumherum ist daraus eine ernstzunehmende Entwicklungsumgebung geworden.

Schnell genug für den spontanen Fix.

Intelligent genug für eine umfangreiche PHP-Anwendung.

Portabel genug, um mir durch eine SSH-Verbindung zu folgen.

Und modular genug, dass ich einzelne Komponenten austauschen oder verfeinern kann, ohne gleich den gesamten Arbeitsplatz neu zu erfinden.

Genau dieser Punkt ist für mich der interessanteste.

Ich habe meine IDE nicht ersetzt.

Ich habe die Annahme ersetzt, dass Programmieren eine voraussetzt.