- Ein Entwickler, der 20 Jahre lang Vim verwendet hat, berichtet von seinen Erfahrungen nach dem Wechsel zum Helix-Editor und dessen Nutzung über drei Monate
- Helix ist besonders attraktiv, weil es Language Server (LSP) standardmäßig unterstützt, ohne komplizierte Konfiguration
- Vor allem die im Vergleich zu Vim/Neovim stärkere Suchfunktion und Multi-Cursor-Unterstützung erleichtern das Erfassen von Kontext in mehreren Dateien und Massenbearbeitungen
- Bei Tasteneingaben hilft ein schnelles Referenz-Popup (quick reference) dabei, Shortcuts nicht zu vergessen und effektiv zu nutzen
- Zwar gibt es einige Unannehmlichkeiten wie fehlende automatische Markdown-Listenerstellung, kein persistentes Undo und etwa einen Crash pro Woche, insgesamt ist die Nutzungserfahrung aber zufriedenstellend
- Das Umlernen von 20 Jahren Vim-Muskelgedächtnis war leichter als erwartet, und statt die Vim-Arbeitsweise zu erzwingen, war es deutlich effektiver, die „Helix-Art“ zu lernen
Warum der Wechsel zu Helix
- Der Anlass für die Nutzung von Helix war, die integrierten Language-Server-Funktionen bequem zu verwenden
- In Vim/Neovim war die Einrichtung von Language Servern komplex, während Helix ohne zusätzliche Konfiguration sofort Sprung zur Definition oder Umbenennen von Symbolen ermöglicht
- Früher mussten zahlreiche Plugins und Konfigurationsdateien gepflegt werden, mit Helix sinkt dieser Aufwand dank eingebauter Unterstützung
Die wichtigsten Vorteile von Helix
- Die Stärke des Suchsystems
- Bei der Suche nach Zeichenketten im gesamten Repository werden die Ergebnisse in einem Vorschaufenster angezeigt, sodass man durch passende Dateien scrollen und gleichzeitig den umgebenden Code sehen kann
- Anders als beim ripgrep-Plugin in Vim ist der Kontext der Ergebnisse deutlich reichhaltiger, was schnelle Entscheidungen erleichtert
- Schnelle Shortcut-Referenz
- Drückt man die Taste
g, erscheint eine Liste möglicher Navigationsbefehle als Hilfs-Popup, was sehr intuitiv ist
- Auch selten genutzte Shortcuts lassen sich leicht nachschlagen, was die Lernkurve flacher macht
Unterschiede zwischen Vim und Helix
- Die Markierungsfunktion verfolgt den Cursor-Verlauf mit
Ctrl+O und Ctrl+I statt mit ma und 'a
- Statt Makros wird hauptsächlich Multi-Cursor-Bearbeitung verwendet
- Für globale Änderungen in einem Dokument: alles mit
% auswählen → mit s per regulärem Ausdruck auswählen → die nötigen Mehrfachbearbeitungen durchführen
- Multi-Cursor ist deutlich bequemer, als jedes Mal ein Makro zu schreiben
- Statt Tabs kann man mit
space + b schnell über den Buffer-Switcher wechseln
Unbequeme Seiten von Helix
- Die Funktion für Text-Reflow ist weniger effektiv als Vims
gq
- Die Kompatibilität mit Listen ist schwächer
- Automatische Erstellung von Markdown-Listen wird nicht unterstützt
- Selbst wenn man am Ende eines Listeneintrags „Enter“ drückt, wird die Liste nicht fortgesetzt
- Für Aufzählungslisten gibt es eine teilweise Lösung, für nummerierte Listen jedoch nicht
- Persistentes Undo ist noch nicht implementiert
- In Vim konnte man mit
undofile Änderungen auch nach dem Beenden rückgängig machen, in Helix fehlt diese Funktion noch
- Automatisches Neuladen von Dateien wird nicht unterstützt
- Wenn sich eine Datei auf der Festplatte geändert hat, muss
:reload-all (:ra<tab>) manuell ausgeführt werden
- Gelegentliche Abstürze
- Etwa einmal pro Woche, möglicherweise im Zusammenhang mit intensiver Markdown-Bearbeitung
- Da man einfach wieder öffnen kann, ist es kein großes Problem
- Trotzdem wird Helix weiterhin verwendet
Der Umstieg und die Lernerfahrung
- Es bestand die Sorge, dass das Umlernen von 20 Jahren Vim-Muskelgedächtnis sehr schwierig sein würde
- Während eines Urlaubs wurde Helix in einem Nebenprojekt eingesetzt, und nach 1–2 Wochen war es nicht mehr verwirrend
- Anfangs wurde versucht, ähnliche Keybindings wie in Vim zu erzwingen, was scheiterte; die „Helix-Art“ zu lernen war viel einfacher
- Es gibt weiterhin einige verwirrende Punkte
- Vims
w und Helix’ w definieren „Wort“ unterschiedlich (Helix schließt das nachfolgende Leerzeichen ein, Vim nicht)
Terminalbasierte Bearbeitungsumgebung
- Da über Jahre hauptsächlich die GUI-Versionen von vim/neovim verwendet wurden, erforderte die Nutzung eines Editors im Terminal etwas Eingewöhnung
- Der schließlich gewählte Workflow
- Für jedes Projekt wird ein separates Terminalfenster verwendet, und alle Tabs dieses Fensters haben dasselbe Arbeitsverzeichnis
- Der Helix-Tab liegt als erster Tab im Terminalfenster
- Das ist praktisch, um mehrere Projekte parallel zu bearbeiten, und könnte sogar besser sein als der frühere Workflow
Konfiguration
- Im Vergleich zu einer mehrere hundert Zeilen langen Neovim-Konfiguration wird eine sehr einfache Konfiguration beibehalten
- Im Wesentlichen werden nur vier Tastenkürzel gesetzt
- Wichtige Konfigurationselemente
- Theme:
solarized_light
- Das Standard-Yank-Register wird auf
+ gesetzt, um mit der Systemzwischenablage zu synchronisieren
# wird als Shortcut zum Umschalten von Kommentaren gesetzt (das Standard-Ctrl+C gefiel nicht)^ und $ werden so umbelegt, dass sie zum Anfang bzw. Ende der Zeile springen (eine andere Methode wollte man nicht lernen)<space>l wird auf :reflow gesetzt (da viel Text geschrieben wird, ist häufiges Reflow nötig; der Vim-Shortcut gq wurde vermisst)
- In einer separaten Konfigurationsdatei
languages.toml werden sprachspezifische Präferenzen festgelegt
- Für Python: Formatter
black, Language Server pyright, automatisches Formatieren deaktiviert
Fazit: Eindruck nach drei Monaten
- Drei Monate sind keine besonders lange Zeit, und es besteht die Möglichkeit, irgendwann zu Vim zurückzukehren
- Früher gab es schon einmal einen Wechsel zu nix und nach acht Monaten die Rückkehr zu Homebrew (für die Verwaltung eines Servers wird NixOS allerdings weiterhin verwendet und als zufriedenstellend empfunden)
- Helix ist noch nicht fertig, aber die Ausrichtung auf einen „konfigurationslosen Editor“ ist klar erkennbar
- Dank seiner Einfachheit und der eingebauten Funktionen hat es langfristig Potenzial als Vim-Ersatz
- Ob es dauerhaft genutzt wird, dürfte jedoch von künftigen Verbesserungen bei Stabilität und Funktionsumfang abhängen
2 Kommentare
Hacker-News-Kommentare
Ich nutze seit Langem Vim/Neovim, habe eigene Konfigurationen gebaut und auch vorgefertigte verwendet, und obwohl ich Vim wirklich mag, ist es sehr attraktiv, dass Helix ohne zusätzliche Konfigurationsarbeit sofort einsatzbereit ist.
Allerdings wirkt die Helix-Konfiguration selbst auf mich ziemlich primitiv, sodass ich denke, dass ich die Umgebung, die ich in Helix bekomme, wohl schon nach den ersten Jahren mit Vim hätte nachbauen können, und dann hätte ich auch keine Config-Hölle mehr gehabt.
Ich finde die Hilfe-Popups großartig, weil sie einem zeigen, welchen Pfad oder welches Keybinding man nehmen muss; ich nutze Dinge wie „Gehe zu Definition“ oder „Gehe zu Referenzen“ nicht so oft und vergesse daher leicht die Shortcuts. Ich würde mir wünschen, dass solche kontextbezogenen Popups breiter übernommen werden, und wenn sie nur dann intelligent erscheinen, wenn man bei der Eingabe zögert, wären sie wirklich nützlich.
Ich nutze Vim/Neovim seit 20 Jahren, habe aber erst vor 6 Monaten das Plugin which-key installiert und verwende es seitdem sehr nützlich.
which-key.nvim GitHub
Ich habe immer wieder versucht, die Konfiguration meines primären Language Servers richtig aufzubauen, damit etwa „Gehe zu Definition“ funktioniert, aber es fühlte sich in Vim oder Neovim einfach zu schwer an, eine angenehme Umgebung herzustellen.
Man hat nicht den Aufwand, Vim-Konfigurationen und zugehörige Abhängigkeiten zu übertragen; die Entwicklungsumgebung fühlt sich viel portabler an, wenn auch nicht so umfangreich wie ein komplexes Vim-Setup.
Besonders nachdem ich in dem Artikel die Erklärung und Screenshots dazu gesehen habe, wünsche ich mir diese Funktion sehr stark.
Wenn das Popup intelligent unter Bedingungen wie einem Timeout erscheint, ist es hervorragend: Es stört nicht, wenn man es nicht braucht, und hilft automatisch genau dann, wenn man zögert.
Davor habe ich hauptsächlich neovim und VS Code verwendet, und Helix füllt für mich eine besondere Lücke.
Ich hatte keine Lust, neovim zu konfigurieren oder weiter bei vim zu bleiben, also brauchte ich etwas zwischen VS Code und nvim, und Helix passt perfekt.
Wenn ich ein vimscript-Meister wäre, würde ich vielleicht anders darüber denken, aber ich bin keiner, also passt es genau.
Ich hoffe, Helix muss nicht modularer werden oder sich stärker wie UNIX verhalten, sondern einfach so weitermachen wie bisher.
Es gibt bereits ein vielfältiges Tooling-Ecosystem, und man kann es auch mit Claude Code integrieren (neue Änderungen werden nach Buffer-Refresh übernommen).
Es ist einer der besten Editoren, deshalb habe ich sogar angefangen, das Projekt monatlich zu unterstützen.
Wenn ich mir für die Zukunft etwas wünschen dürfte, dann vor allem Bild- oder Formel-Rendering direkt im Editor; ich hoffe, dass so etwas über Plugins mit dem Kitty-Terminal-Protokoll oder sixel umgesetzt wird.
Besonders beim Arbeiten an Notizen/Blogs in Markdown-Dateien wäre das sehr nützlich.
Ich wünsche Helix weiterhin viel Erfolg.
Bei VSCode oder (neo)vim muss man Plugins aus allen möglichen Quellen beziehen, und das hat mich immer verunsichert.
Ich bin zwar kein Lua-Entwickler, aber LLMs helfen enorm dabei, nvim-Konfigurationen zu erstellen oder anzupassen.
Der größte Grund, warum ich zu helix gekommen bin, ist, dass LSP- und Linting-Setup dort so gut gelöst sind.
Ich teile ein paar Dinge zu Funktionen, die auf HEAD bereits gemergt sind —
Da es bereits einen eingebauten Dateipicker auf Basis von Fuzzy Search gibt, bringt ein klassischer Datei-Explorer ohnehin nicht so viel zusätzlichen Nutzen.
Ich habe auch ein Vim-Keybinding-Plugin für Helix ausprobiert, aber weil es nur teilweise passte, war die Enttäuschung noch größer.
Ich würde gern wissen, wie erfahrene Helix-Nutzer damit umgehen.
In Vim/Neovim war es mir einfach zu viel Arbeit geworden, eine angenehme LSP-Umgebung aufzusetzen, deshalb bin ich zu Helix gewechselt.
In den letzten fünf Jahren sind in Neovim aber Distributionen entstanden, die gewissermaßen „batteries included“ sind und sich sehr einfach einrichten lassen.
Ich stimme zu, dass viele Entwickler keine Zeit mit Editor-Debugging verbringen wollen; ich glaube, genau deshalb ist JetBrains so beliebt.
Dass ein Neovim-Nutzer mit 20 Jahren Erfahrung nie eine brauchbare LSP-Umgebung eingerichtet haben soll, finde ich allerdings etwas schwer nachvollziehbar, und ich frage mich, ob das wirklich die ehrliche Erfahrung des Autors ist.
Letztlich war es sogar dann bequemer, einfach eine komplette IDE zu benutzen, sodass es immer wieder Hemmungen bei Installation und Einrichtung gab.
Ich kann den geschilderten Fall gut nachvollziehen.
Ich halte meine Konfiguration ebenfalls minimal und barebones, und es war nicht schwer; Lua fühlt sich für mich viel ergonomischer an als vimscript.
Das ist auch ein Grund, warum ich weiterhin Tools wie ALE verwende.
Ich hoffe, du bist glücklich mit Helix.
Andere Editoren kann man zwar nutzen, aber fast alles rund um Debugging und Konfiguration ist auf vscode ausgerichtet, sodass dessen Nutzung praktisch empfohlen wird.
Auch Neovim+treesitter+LSP läuft inzwischen sehr reibungslos; selbst wenn es früher mühsam war, ist es heute kein großes Problem mehr.
Wenn die Motivation für Helix ausgerechnet LSP ist, finde ich das fraglich; vielleicht ist das eigentliche Problem des Autors eher eine Unzufriedenheit mit LSP selbst.
Einer der Nachteile des Nomen-Verb-Ansatzes ist, dass Wiederholungsbefehle (
.) nicht möglich sind.In Vim kann man Aktionen wie
dd..oderdap..wiederholen, aber im Nomen-Verb-Modell ist das schwierig.Grundsätzlicher gibt es auch ein Problem mit zu wenigen Tasten.
Für zu viele Basisoperationen muss man die Alt-Taste verwenden, und anders als bei vim gibt es nicht normal/visual/insert, sondern nur visual/insert.
Selbst die Trennung zwischen motion und Objekt ist nicht klar, was das Keymapping schwieriger macht und den Tastenmangel verschärft.
Tatsächlich fühlt er sich besser abgestimmt auf die Art an, wie man beim Schreiben von Code denkt.
Das ist eine von echasnovski erstellte Plugin-Sammlung, die viele unterschiedliche Bedürfnisse abdeckt und zugleich Konsistenz und gute Dokumentation bietet.
Ab nvim 0.12 (nightly) reicht es, mit dem eingebauten Plugin-Manager (
vim.pack) einfach mini.nvim und lspconfig zu installieren.offizielle mini.nvim-Seite
mini.nvim GitHub-Repository
Ich nutze neovim ohne Plugins, ohne Autovervollständigung und sogar ohne Syntax-Highlighting.
Ich habe das Gefühl, dass diese Art von Selbstdisziplin mich dazu bringt, besseren Code zu schreiben.
Das ist sicher nicht für jeden etwas, aber ich würde empfehlen, es wenigstens einmal auszuprobieren.
Code-Actions oder „goto definition“ nutze ich ebenfalls nicht; höchstens Live-Fehler manchmal, aber Compiler sind inzwischen so schnell, dass das kaum noch wichtig ist.
Ich würde LSP am liebsten ganz abschalten; ich habe nicht das Gefühl, dass LSP meine Programmierfähigkeiten im Vergleich zu vor 20 Jahren massiv verbessert hat.
Was Syntax-Highlighting angeht, finde ich, dass knallbunte Themes eher die Konzentration stören und keinen echten Mehrwert bieten.
Ich bevorzuge einfarbige oder höchstens zweifarbige Themes und brauche nicht einmal unterschiedliche Farben für Variablen- und Funktionsnamen.
Trotzdem frage ich mich, ob die Belastung, sich alles merken zu müssen, nicht mit der Zeit ermüdet, oder ob dieser Ansatz tatsächlich zu besserem Code führt.
Farben sind eine zusätzliche Informationsebene, die Fehler oder Irrtümer im Code sichtbarer macht und die Navigation im Code beschleunigt.
Ich gehe aber nicht ganz so weit und lasse immerhin Syntax-Highlighting sowie Feedback zu Syntaxfehlern über LSP aktiviert.
Autocomplete oder automatische Verlinkung zur Dokumentation verwende ich dagegen nicht.
helix-editor.vercel.app
Sie ist viel angenehmer zu lesen als die offizielle Dokumentation und enthält viele Tipps und Tricks, die effiziente Bearbeitungsweisen oder Keybindings vermitteln und einige Schwächen von Helix (wie das fehlende integrierte Terminal) abmildern können.
Wer lange vim genutzt hat, dem würde ich kickstart empfehlen (insbesondere den modularen Fork kickstart-modular.nvim).
kickstart.nvim
Das ist ein hervorragender, sehr minimalistischer Startpunkt.
Sie ist allerdings ziemlich groß, daher verwalte ich sie leichter, indem ich Bereiche mit Fold-Markern einklappe.
Ich interessiere mich wegen der einfachen Einrichtung von LSP, Plugins usw. immer wieder für Helix, aber meine Hände sind zu sehr an vi/vim gewöhnt, sodass der Umstieg nicht leichtfällt.