Ein Liebesbrief an Neovim

 (caio.ca)
1 Punkte von GN⁺ 7 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Neovim lässt einen Codebearbeitung nicht als schnelles Tippen begreifen, sondern als wiederholte Schleife aus Bewegen, Ändern, Löschen, Umstrukturieren und Prüfen von Tests
  • Die Bearbeitungsgrammatik von Vim reduziert mit kombinierbaren Operationen auf Bedeutungsebene wie ci", dap, ., Makros und Textobjekten die Reibung bei wiederholten Änderungen
  • Neovim erzwingt keinen Explorer, kein Terminal und kein Git-Panel, sondern lässt Nutzer rund um Buffer selbst wählen, wie sie Telescope, Fugitive, LSP und anderes einsetzen
  • Die Konfiguration bleibt als in Git gespeicherte Dateien im eigenen Besitz und als Teil eines Systems erhalten, das mit Shell, tmux, ripgrep, git und Language Servern zusammenarbeitet
  • Mit Lua, integriertem LSP, Treesitter und Lazy.nvim wurde Neovim modernisiert, doch der eigentliche Wert liegt darin, dass gelernte Abläufe sich über lange Zeit ansammeln und der Workflow sich direkt weiterentwickelt

Vom Vim-Gefühl zu Neovim

  • Die Nutzung von Vim begann 2011, und anfangs wurde einfach eine .vimrc kopiert, ohne überhaupt zu verstehen, warum j keinen Buchstaben eingibt, sondern den Cursor bewegt
  • Die erste Woche war hart und der erste Monat ungewohnt, doch nachdem das Modell von Vim vertraut geworden war, wirkten andere Editoren so, als läge zwischen Code und Nutzer eine Dämpfungsschicht
  • Es wurden viele Editoren ausprobiert, darunter VS Code, JetBrains-IDEs, Sublime, Atom und Zed; JetBrains-Werkzeuge sind sehr mächtig, und VS Code ist für fast alle mehr als gut genug und leicht erweiterbar, was seinen Erfolg erklärt
  • Trotzdem wird Neovim weiter genutzt, weil es sich an die eigene Arbeitsweise anpasst und die wiederkehrende Schleife der Codebearbeitung direkt unterstützt

Bearbeiten nicht als Tastenkürzel, sondern als Sprache

  • Code zu bearbeiten bedeutet weniger, schnell zu tippen, sondern eher wiederholt zu navigieren, kleine Änderungen vorzunehmen, falsche Abstraktionen zu entfernen, Funktionen umzustrukturieren, Dateien zu verschieben und Tests sowie Diagnosen zu prüfen
  • Die meisten Editoren behandeln Text als Dokument und die Tastatur als Eingabegerät, doch Vim behandelt Bearbeitung wie eine Grammatik
  • ci" ändert den Inhalt innerhalb von Anführungszeichen, dap löscht einen Absatz und . wiederholt die letzte Änderung
  • Makros lassen sich einmal für eine kleine Routine anlernen und dann auf eine ganze Datei anwenden, und Textobjekte ermöglichen Operationen auf Bedeutungseinheiten statt auf einer Anzahl von Zeichen
  • Sobald die Vim-Grammatik in Fleisch und Blut übergeht, muss man seltener Code mit der Maus ziehen, Sidebars anklicken oder für Aufgaben, die täglich Dutzende Male vorkommen, die Command Palette öffnen
  • Häufige Aufgaben werden zu kleinen, direkten Bewegungen, und auch das Rauschen des Editors nimmt ab

Neovim erzwingt keinen Workflow

  • GUI-zentrierte Editoren haben oft eine feste Vorstellung davon, wo Explorer, Terminal, Git-Panel und Debugger sitzen und wie sie aussehen sollen; mit der Zeit wirkt der Editor dann wie ein Cockpit
  • Neovim beginnt beim Buffer, und was darum herum platziert wird, entscheidet der Nutzer
  • Wenn ein Dateibaum nötig ist, kann er ergänzt werden, und für Fuzzy-Suche lässt sich ein passendes Werkzeug wie Telescope oder fzf-lua auswählen
  • Für Git-Integration kann Fugitive genutzt werden, und LSP, Diagnosen, Formatierung, Snippets, Treesitter, Test-Runner und Autovervollständigung lassen sich einsetzen, ohne dass alles wie ein träges Electron-Dashboard wirkt
  • Geschwindigkeit ist nicht nur eine Frage der Startzeit, sondern eine Frage des Vertrauens
    • Wenn man eine Taste drückt, muss sofort eine Reaktion kommen
    • Beim Öffnen großer Dateien darf nicht die gesamte UI stocken
    • Auch bei SSH-Zugriff, tmux-Pairing oder Änderungen in einem kleinen Terminalfenster muss sich der täglich genutzte Editor gleich anfühlen
  • Ob lokales Projekt, entfernter Server, schnelle Konfigurationsänderung, große Rails-App, kleines Shell-Skript oder das Schreiben von Markdown: Es können dieselben Bewegungen, dieselben Befehle und dasselbe Muskelgedächtnis genutzt werden
  • Diese Konsistenz summiert sich über eine gesamte Laufbahn hinweg

Eine beherrschbare Konfiguration und ein Werkzeug als Teil des Systems

  • Die Neovim-Konfiguration besteht aus Dateien in Git, sodass man sie selbst lesen, kaputtmachen und zur Hälfte löschen kann, wenn einem klar wird, dass ein Plugin gar nicht gebraucht wird
  • Man ist nicht auf mysteriöse Konfigurationsdatenbanken, halb verstandene Synchronisationszustände von Konten oder Erweiterungen angewiesen, die im Hintergrund seltsam reagieren, weil sich vor einigen Releases ein Kontrollkästchen geändert hat
  • Viele moderne Editoren wollen der Ort sein, an dem alles geschieht, doch Neovim begnügt sich damit, ein scharfes Teil eines größeren Systems zu sein
  • Es versucht nicht, die Shell zu ersetzen, sondern arbeitet mit tmux, ripgrep, git, Language Servern, Formatierern, Lintern und Test-Runnern zusammen
  • Dass es nicht den ganzen Schreibtisch besitzen muss, ist ebenfalls einer der Gründe, warum Neovim so dauerhaft geblieben ist
  • Seit 2011 sind viele Editoren, Erweiterungsökosysteme, Themes, Marktplätze und AI-Panels aufgetaucht, doch Vim war schon damals ein altes Werkzeug, und Neovim hat die nötigen Teile modernisiert, ohne den Grund aufzugeben, warum Menschen es schätzen

Modernisierung und der langfristige Ertrag des Lernens

  • Lua hat die Konfiguration verbessert, und auch das Plugin-Ökosystem hat sich stark weiterentwickelt
  • Das integrierte LSP bringt IDE-Funktionen in den Editor, ohne aufgebläht zu wirken
  • Treesitter hat Syntax-Highlighting und Codeverständnis modernisiert, und Lazy.nvim macht Plugin-Management schnell und einfach
  • Der zentrale Reiz von Neovim liegt darin, dass Gelerntes mit der Zeit weiter nützlich bleibt
    • Wenn man eine Motion lernt, hilft sie dauerhaft
    • Wenn man ein Makro schreibt, verschwindet langweilige Bearbeitungsarbeit
    • Wenn man Textobjekte entdeckt, werden lästige Refactorings leichter
    • Wenn man einen Befehl anpasst, wird er Teil der eigenen Hand
  • Ein Editor wird nicht besser, weil ein Unternehmen eine neue Sidebar veröffentlicht, sondern weil der Nutzer lernt, besser mit ihm umzugehen
  • Produktivität lässt sich schwer nur damit messen, dass „hier 5 Sekunden gespart wurden“; sie liegt in der verringerten Reibung über Tausende kleiner Bearbeitungen hinweg
  • Beim Wechseln zwischen Code, Tests, git diff und Suchergebnissen kann man auf das Problem fokussiert bleiben, ohne das Gefühl zu haben, in einen anderen Raum zu wechseln
  • Neovim ist so gut programmierbar, dass man nicht einfach Standardvorgaben hinnimmt, sondern den Workflow selbst formt
  • Wenn sich etwas Unbequemes zweimal wiederholt, lässt es sich meist mit einem Mapping, einem Befehl, einer kleinen Lua-Funktion, einem besseren Plugin oder durch das Entfernen eines Plugins beheben
  • Die Konfiguration entwickelt sich passend zur tatsächlichen Arbeitsweise weiter, und wenn klar ist, welche Änderung gewünscht ist, steht nur noch sehr wenig zwischen Gedanke und Bearbeitung
  • In 15 Jahren haben sich Sprachen, Frameworks, Maschinenleistung und Branchentrends verändert, doch Vim und Neovim sind weiterhin die zentralen Editoren geblieben, in denen die beste Arbeit entsteht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 7 시간 전
Lobste.rs-Kommentare

  • Ich habe vor 12–14 Jahren angefangen, vim zu benutzen, weil ich einen leichten Editor brauchte, der den Code direkt vor mir anzeigt.
    Ich fing an, ohne Maus zu arbeiten und es zu lernen, und später freute ich mich, als ich erfuhr, dass Mitchell Hashimoto vim auf ähnliche Weise gelernt hatte.
    Auf neovim wurde ich durch TJ DeVries(https://www.youtube.com/@teej_dv) und seinen YouTube-Kanal aufmerksam, wo ich sah, wie er an neovim, telescope und verschiedenen anderen Projekten hackte.
    Der Wechsel zu Lua fühlte sich natürlich an, und da ich die kleine Sprache ohnehin mochte, gefiel mir das sehr.
    Die ersten Plugins, die ich benutzte, waren treesitter und telescope, und auch heute verwende ich neovim noch zusammen mit ein paar kleinen Plugins.
    neovim ist mir nie kaputtgegangen und funktioniert einfach. Ich nutze keine LLM-Plugins und finde, dieses Ökosystem kann auch außerhalb des Editors existieren.
    Ich hoffe, dass das Team weiterhin nur einen leichtgewichtigen und fokussierten Code-Editor bereitstellt.

    • Ähnliche Erfahrung. Ich habe jahrelang vim und emacs benutzt und vim bevorzugt, war aber immer ein wenig neidisch darauf, dass elisp eine ziemlich brauchbare Programmiersprache ist, während vimscript eher nicht so war.
      Deshalb wirkte es für mich äußerst attraktiv, dass neovim Lua hinzugefügt hat.

  • Vor etwa 20 Jahren habe ich einmal darüber nachgedacht, was meinen Alltag unabhängig von bloßer Produktivität angenehmer macht.
    Ganz oben auf der Liste standen linux und vim.
    Egal, welche Arbeit ich machte oder welchen Tech-Stack ich nutzte, diese beiden sorgten immer für eine ergonomische, vertraute und gemütliche Arbeitsumgebung.

  • 2009, während ich Vorstellungsgespräche führte, begann ich, mehr von vim als nur :wq zu lernen. Alle Mitarbeitenden benutzten vim, und um mit ihnen zusammenzuarbeiten, gab es für mich keinen anderen Weg.
    Einige hatten sogar die Pfeiltasten deaktiviert.
    Davor beschränkte sich meine Erfahrung mit Terminal-Editoren auf pico im Studium, und normalerweise benutzte ich die damals populären GUI-Editoren.
    Zum Glück wurde ich eingestellt, und seitdem bin ich bei vim geblieben.
    In letzter Zeit ist mir klar geworden, dass sich die Art zu denken, die ich durch vim gelernt habe, auch auf andere Bereiche meines Software-Alltags ausgedehnt hat.
    Angefangen hat es wohl damit, dass ich auf macOS mit Hammerspoon eine virtuelle Tastatur für Submaps zur Fensterverwaltung gebaut habe, und als ich Ende letzten Jahres Arch Linux ausprobierte, wurde Tiling Window Management plötzlich sehr einfach.
    Vor einiger Zeit bin ich auf neovim umgestiegen, und ich halte es für wirklich großartig.
    Ich weiß, dass es viele Scherze und Diskussionen über Editoren gibt, aber abgesehen von ein paar Ausnahmen fällt es mir immer noch schwer zu verstehen, wie Menschen, die beruflich Code schreiben, nicht vim, emacs oder etwas Ähnliches benutzen.
    In jedem Beruf ist es wichtig, die besten Werkzeuge für die Arbeit zu wählen, und Bearbeitung wie eine Sprache zu behandeln ist in der Softwareentwicklung ein großer Vorteil.

    • Der Kern des Artikels ist „Warum liebe ich Neovim“ und nicht „Warum sollte man es benutzen“.
      Zu der oben genannten Stelle mit dem „schwer zu verstehen“: Auch das Verhalten, die Shortcuts und die Plugins von Editoren wie VS Code sind sehr nützlich.
      Es lohnt sich, die Dokumentation von VS Code wirklich zu lesen, denn es kann tatsächlich eine Menge.
      Und für manche von uns, mich eingeschlossen, ist es einfach und schnell genug, den Cursor mit der Maus an eine beliebige Stelle im Buffer zu setzen und einen beliebigen Bereich auszuwählen.
      KISS passt hier.
    • Vi-Modus und Bewegungsbefehle nutze ich fast überall, aber vi, vim, neovim und emacs mit viper verwende ich nur gelegentlich.
      Denn oft sind andere Editoren für die jeweilige Aufgabe die besseren Werkzeuge.
      Für Python, das ich derzeit am häufigsten benutze, empfinde ich PyCharm als das bessere Werkzeug gegenüber ihnen.
      Zum Glück gibt es mit IDEAVim ein sehr gutes Plugin, sodass das Muskelgedächtnis erhalten bleiben kann.
      Auf dem Mac ist außerdem praktisch, dass sich System-Shortcuts nicht mit vi-Shortcuts überschneiden, sodass man je nach Situation die jeweils passende Variante wählen kann.
      Wenn ich C++ verwende, halte ich CLion für das bessere Werkzeug, aber auch dort funktioniert IDEAVim.
      Für Kleinkram mit unscharfer Kategorie benutze ich oft zed, und auch dessen vim-Emulation ist ziemlich gut.
      Wenn man sich auf ein Remote-System aufschaltet, ist es natürlich gut, einen brauchbaren Terminal-Editor zu haben, aber wenn ich eine vollständige GUI nutzen kann, mag ich Terminal-Editoren nicht besonders.
      Modales Editieren an sich mag ich, aber wenn man das Muskelgedächtnis nicht aufgeben muss, gibt es meiner Ansicht nach auch gute Gründe für einen GUI-Editor.

  • VS Code ist schon im Auslieferungszustand für viele Einsatzzwecke gut genug.
    Es bietet bereits ctrl-p-Dateisuche, Splits, Syntax-Highlighting und Unterstützung für populäre Sprachen.
    Ich hatte gehofft, dass neovim zumindest standardmäßig etwas wie ctrl-p bietet und so etwas wie das Linux Mint unter den vim-artigen Editoren wird, mit geringeren Sicherheitsbedenken und niedrigerer Konfigurationshürde.
    Ich kann gut nachvollziehen, dass man beim Pair Programming in einer tmux-Session auf einer per SSH erreichten Maschine oder beim Beheben eines Problems in einem kleinen Terminalfenster dasselbe Editor-Gefühl nutzen möchte wie im Alltag.
    Ich habe viel Code gegen Bezahlung über screen/vim via SSH geschrieben, und bevor es diese ständigen Unterbrechungen durch jederzeit aufpoppendes Slack gab, war das tatsächlich enorm produktiv.
    Visuelle Debugger wie in Visual Studio oder Jetbrains-IDEs wie CLion und Rider waren immer der eine Bereich, für den ich in keinem vim-Editor einen wirklich guten Ersatz gefunden habe.
    Sie haben eine Stärke, die zugänglicher ist als etwas wie cgdb.
    Geschwindigkeit ist nicht nur eine Frage der Startzeit, und neovim ist in dieser Hinsicht auch gut, aber das Beenden von standardmäßigem neovim ist spürbar langsamer als bei vim.
    Es dauert zwar nicht extrem lange, aber in meiner Umgebung etwa eine Sekunde.

  • Ich mag das vim-Modell. Modales Editieren ist nur ein kleiner Teil davon; was ich an vim gegenüber helix oder einer normalen IDE höher schätze, ist, dass man es schrittweise lernen kann.
    Zuerst versteht man Keybindings und das Setzen von Optionen, dann fügt man Bedingungen in die Konfiguration ein, wenn unter Windows etwas nicht funktioniert, danach schreibt man autocmds und Funktionen und erweitert das mit dem zuvor Gelernten schließlich zu kleinen Plugins.
    Das heißt aber nicht, dass ich vim oder neovim wirklich liebe.
    In vim gibt es seit Jahrzehnten dieselben seltsamen Bugs, die nie behoben wurden, und neovim hat viele Bugs behoben, dafür aber andere eingeführt.
    Die größte Sünde von neovim ist, bei jedem Update die Lua-API kaputtzumachen.
    Ich bin es leid, bei jedem Start Deprecation-Warnungen zu sehen und erst meine Konfiguration reparieren zu müssen, bevor ich das tun kann, was ich eigentlich tun wollte.
    Wenn einige der neuen Funktionen nicht ausschließlich für Lua verfügbar wären, wäre das wenigstens weniger schlimm.
    Andernfalls könnte ich einfach weiter nur vimscript benutzen und mit der über 20 Jahre gewachsenen Kompatibilität zufrieden sein.