Helix: Ein postmoderner Texteditor

 (helix-editor.com)
3 Punkte von GN⁺ 2026-03-08 | 1 Kommentare | Auf WhatsApp teilen
  • Helix ist ein terminalbasierter modaler Texteditor, ein Open-Source-Projekt mit integrierten modernen Funktionen
  • Durch die Integration von Tree-sitter bietet er syntaxbewusste Bearbeitungsfunktionen wie Syntax-Highlighting, Berechnung von Einrückungen und Code-Navigation
  • Er unterstützt das Language Server Protocol und realisiert damit Funktionen auf IDE-Niveau wie Autovervollständigung, Sprung zur Definition, Dokumentationsansicht und Diagnosen
  • Er ist in Rust geschrieben und funktioniert ohne Electron oder JavaScript, wodurch er sich effizient in SSH-, tmux- und Terminal-Umgebungen nutzen lässt
  • Plugin-System und GUI-Frontend sind für die zukünftige Entwicklung geplant; charakteristisch sind eine schlanke Codebasis und moderne Standardeinstellungen

Hauptmerkmale

  • Helix verwendet ein von Kakoune inspiriertes Multi-Selection- und Cursor-System als zentrale Bearbeitungseinheit
    • Befehle können mehrere Auswahlbereiche gleichzeitig bearbeiten und ermöglichen so paralleles Editieren von Code
  • Mit Tree-sitter wird ein fehlertoleranter Syntaxbaum erzeugt
    • Dadurch werden präzises Syntax-Highlighting, automatische Einrückung und Code-Navigation unterstützt

Funktionen für Code-Manipulation und Navigation

  • Es bietet Auswahl- und Bewegungsfunktionen auf Ebene von Syntaxbaum-Knoten wie Funktionen, Klassen und Kommentaren
    • Dadurch ist Bearbeitung auf Basis der syntaktischen Struktur statt nur von reinem Text möglich
  • Über das Language Server Protocol (LSP) stehen sprachspezifische Funktionen wie Autovervollständigung, Sprung zur Definition, Dokumentationsansicht und Diagnosen zur Verfügung
    • So lassen sich Funktionen auf IDE-Niveau ohne zusätzliche Konfiguration in der Terminal-Umgebung nutzen

Technische Grundlage

  • Geschrieben in Rust, wodurch Stabilität und Performance sichergestellt werden
    • Verwendet weder Electron, VimScript noch JavaScript
    • Lauffähig in SSH-, tmux- und gewöhnlichen Terminal-Umgebungen
    • Die schlanke Struktur verbessert die Akkueffizienz

Eingebaute moderne Funktionen

  • Ein Fuzzy Finder unterstützt die Suche nach Dateien und Symbolen sowie die projektweite Suche
  • Verschiedene Komfortfunktionen wie automatisches Schließen von Klammern, integriertes Surround und Anpassung von Themes sind eingebaut
  • Eine Struktur, in der umfangreiche Grundfunktionen bereits ohne separate Plugins integriert sind

Häufig gestellte Fragen

  • Die Bezeichnung „postmodern“ ist scherzhaft gemeint: Wenn Neovim ein „modernes Vim“ ist, dann ist Helix die nächste Generation danach
  • Ein GUI-Frontend soll künftig als WebGPU-basierter Prototyp entwickelt werden
  • Derzeit ist kein Plugin-System implementiert, eine spätere Einführung ist jedoch geplant
  • Der Unterschied zu Kakoune besteht darin, dass Helix mehr Funktionen integriert und Tree-sitter-basierte Code-Analyse nutzt
  • Anders als Vim wurde Helix von Grund auf neu entworfen, hat eine kleinere Codebasis und bietet moderne Standardwerte mit minimalem Anpassungsbedarf der Konfigurationsdatei

Community und Mitmachen

  • Code-Beiträge sind auf GitHub möglich
  • Projektdiskussionen finden im Matrix-Kanal statt
  • Entwicklung kann über OpenCollective unterstützt werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-08
Hacker-News-Kommentare

  • Der Witz mit „Post-modern?!“ fand ich interessant.
    Viele Engineers verstehen „postmodern“ einfach als die nächste Stufe nach modern, aber das entspricht nicht der ursprünglichen Bedeutung in Kunst und Geisteswissenschaften.
    Natürlich ist diese Verwendung kein großes Problem, aber es fiel mir trotzdem auf, weil ich auf wirklich „postmoderne“ Kreativität gehofft hatte.

    • Es hieß einmal, Thiel und Luckey hätten Tolkien missverstanden; mich würden konkrete Beispiele interessieren.
    • Als ich den Witz von Helix zum ersten Mal gesehen habe, dachte ich auch dasselbe.
      Da „postmodernism“ aber ursprünglich als Reaktion auf den Modernismus entstanden ist, ist die Deutung als einfach „nach modern“ auch nicht völlig falsch.
      Mit der Zeit ist die Bedeutung allerdings viel komplexer geworden, und gerade deshalb wirkt es heute fast schon witzig „dated af“.
      „Helix, der erste Editor, der nicht an Meta-Erzählungen glaubt. Helix, der relativistische Editor. Helix, jetzt mit den neuesten Updates von Foucault und Derrida.“
    • An all dem ist Perl schuld. Dort hat diese Art der Benennung angefangen.

  • Ich nutze Helix seit einigen Jahren als meinen Haupteditor (Sublime → Atom → Vim → Helix).
    Die meisten LSPs funktionieren fast ohne Konfiguration, und die Konfigurationsdatei ist viel kompakter als früher meine .vimrc.
    Es hat nur ein paar Tage gedauert, meine Vim-Muscle-Memory umzustellen, aber ich habe immer noch gemischte Gefühle gegenüber modalen Editoren.
    Auf Code-Folding warte ich allerdings noch.

    • Da ich Emacs und Vim parallel nutze, würde mich interessieren, was genau an modalem Editing unangenehm ist.
      In Emacs kann man mit multiple cursors und treesitter-basierten Plugins auch ohne Modalität sehr mächtig editieren.
      Vielleicht ist der modale Ansatz von Helix aus ähnlichen Gründen unangenehm?
    • Mein Problem ist immer noch die Escape-Taste.
      Auf alten Unix-Tastaturen lag sie nahe an der Home Row, heute ist sie viel zu weit weg.
      Die meisten Tutorials erwähnen keine Alternativtaste, und ich verstehe bis heute nicht, warum noch immer mehr als die Hälfte der Nutzer einfach Escape weiterverwendet.

  • Ich habe Helix vor ein paar Tagen wieder ausprobiert. Dass man AI nur über LSP nutzen kann, ist okay,
    aber dass Dateien bei externen Änderungen nicht automatisch neu geladen werden, war extrem unpraktisch.
    Man macht sich ständig Sorgen, ob die von der AI bearbeitete Datei wirklich auf dem neuesten Stand ist.

    • GitHub Copilot, Claude Code und Codex ändern Dateien direkt über eine IDE-API und bieten auch eine Diff-Ansicht.
      Dieser Ansatz ist deutlich robuster und attraktiver.
      Manche AI-Tools behaupten dagegen, man brauche keine IDE und alles solle CLI-zentriert laufen; das halte ich für völligen Unsinn.
    • Keine perfekte Lösung, aber Helix hat die Befehle :reload und :reload-all.
      Ich habe Ctrl-r auf reload-all gelegt.
    • Das lässt sich mit einem einfachen Patch beheben → GitHub-PR-Link
    • Ich hatte dasselbe Problem und habe meinen Workflow dann so geändert, dass lazygit Dateiveränderungen überwacht und ich nur noch in Helix bearbeite.
      Eine weitere Option ist mux; dort kann man Änderungen, die ein LLM vorgeschlagen hat, zeilen- oder blockweise kommentieren (noch in einer frühen Version).
    • Mit der Zeit fand ich es sogar angenehm, dass es kein automatisches Neuladen gibt.
      Wenn ich mit Claude Code arbeite, gefällt es mir, dass Dateien nicht automatisch verändert werden.

  • Vim ist C, Helix ist C++, Ki Editor ist Rust.
    Helix hat viele Ideen von Vim übernommen, aber es fehlt an Konsistenz bei den Keybindings, und auch die konzeptionelle Komponierbarkeit ist schwächer.
    Zum Beispiel bewegt man sich in Buffern mit k, im Dateiexplorer muss man aber ctrl+n verwenden.

    • Warum ist Ki denn wie Rust? Ich finde, Helix ist ebenfalls ein ziemlich cooler Editor.
    • Ich bin überrascht zu hören, dass Helix jetzt einen Dateiexplorer hat. Gerade weil es den nicht gab, hatte ich es damals nicht genutzt.
    • In Vim gibt es eine ähnliche Situation. Im Autocomplete-Fenster kann k nicht verwendet werden, weil es dort als Eingabezeichen gilt, daher braucht man andere Tasten.
      Vermutlich ist es bei Helix derselbe Grund.
    • Ich kann mit dem Konzept von an Tastenpositionen orientierten Bindings nichts anfangen.
      Was passiert denn bei einer SSH-Verbindung, wenn das Tastaturlayout anders ist?
    • Die Aussage „Helix ist C++“ wirkt auf mich wie eine überzogene Metapher. Wenn Vim C ist, dann ist Neovim eher C++.

  • Ich wollte Helix wirklich mögen.
    Die Standardeinstellungen sind gut, und ich habe meine Vim-Gewohnheiten bewusst abgelegt, um es richtig zu lernen.
    Am Ende kam ich aber zu dem Schluss, dass die Keybindings Kompromisse zugunsten einer einfachen Implementierung sind.
    Für kleine Änderungen bin ich jetzt wieder bei Neovim, für größere Arbeiten bei Zed (im Vim-Modus).

    • Hast du Ki Editor ausprobiert? Aus UX-Sicht ist das Modell weiter als bei Helix.
    • Als langjähriger Vim-Nutzer fand ich das übermäßig meinungsstarke Design von Helix unangenehm.
      Wenn man zum Beispiel eine Datei erneut öffnet, springt der Cursor nicht an die frühere Position zurück.
      Mit einem LLM hätte ich das zwar ändern können, aber am Ende wollte ich keinen Helix-Fork pflegen.
    • Es gibt auch eine Version mit Vim-Bindings namens evil-helix. Einen Versuch wäre es wert.
    • Dass die Bindings anders sind als in Vim, war letztlich der Grund, warum ich aufgegeben habe.
      Jahrelang aufgebaute Muscle-Memory wegzuwerfen, ist wirklich schwer.
    • Ich stimme nicht zu, dass die Helix-UI nicht einfach sei.
      Die Kombination aus hx + Zed finde ich ziemlich stark.

  • Weil Helix keine Live-Dateiaktualisierung unterstützt, ist es umständlich, es zusammen mit Code-Agenten zu verwenden.

  • Ich würde empfehlen, die zweite Frage in den FAQ von Helix anzuschauen.
    Dass das Python-LSP ohne Konfiguration sofort funktioniert, fand ich beeindruckend.
    Aber wegen meiner über 25 Jahre aufgebauten Vim-Muscle-Memory sind die kleinen Unterschiede in Helix unglaublich verwirrend.
    Am Ende ist nicht Helix das Problem, sondern meine Muscle-Memory.

    • Nach langer Zeit mit einer ergonomischen Tastatur war die Rückkehr zu einer normalen Tastatur anfangs auch schwer, aber irgendwann gewöhnt man sich an beides.
      Bei Vim und Helix könnte es genauso sein.
    • In Emacs kann man M-ESC ESC auf einen harmlosen Befehl legen, damit sich nicht versehentlich Fenster schließen.
      Zum Beispiel: (global-set-key (kbd "M-ESC ESC") 'keyboard-quit)
    • Hast du den Evil-Modus in Emacs ausprobiert? Der Umstieg von Vim war bei mir fast reibungslos.
    • Ich habe Vim ebenfalls 25 Jahre lang benutzt, bin inzwischen aber komplett zu Helix gewechselt.
      Wenn man sich erst an Unterschiede wie dd und G gewöhnt hat, gefällt es einem mit der Zeit immer besser.
    • Zed behält die Helix-Philosophie (LSP-Unterstützung standardmäßig) bei und bietet gleichzeitig exakte vi-Bindings.

  • Ich nutze Helix seit einigen Jahren als Standardeditor.
    Besonders gefallen mir die Einfachheit, die Geschwindigkeit, die tastaturzentrierte Navigation und die Integration des Elixir-LSP.

  • Ich verwende Helix als Haupteditor und habe damit viel Code produktiv ausgeliefert.
    Meine Konfigurationsdatei hat nicht einmal 50 Zeilen, und ich habe nur ein paar Vim-Tasten ergänzt.
    Auch der Wechsel zwischen Vim und Helix ist für mich kein großes Problem.
    Meine Konfiguration ist hier zu finden.

  • Ich habe direkt in VS Code selbst eine Erweiterung für einen modalen Modus gebaut, und der Ansatz von Kakoune und Helix war interessant.
    Die Struktur, bei der man vorab sieht, was geändert wird, und das auf Multiple Cursors ausgerichtete Design wirkten nachvollziehbar.
    Nach ein paar Wochen bin ich aber doch wieder zum klassischen Vim-Stil zurückgekehrt.
    Der Multiple-Cursor-Ansatz war nur dann nützlich, wenn man alle Änderungen gleichzeitig auf dem Bildschirm sehen konnte.
    Heute schreibe ich dank AI häufiger Text statt Code, deshalb scheint mir der Wert dieser Editierweise geringer geworden zu sein.

    • In Emacs gibt es den Befehl mc-hide-unmatched-lines, mit dem nur die Zeilen mit Cursor sichtbar bleiben.
      Multiple Cursors sind für kurze, einfache Änderungen gut, aber bei komplexeren Modifikationen sind Batch-Editing-Tools effizienter.
    • Die Funktion Reveal Cursors im Ki Editor wurde genau dafür entwickelt, das Problem mit Cursorn außerhalb des sichtbaren Bereichs zu lösen.
    • Allein die Möglichkeit, „alle Änderungen auf einen Blick“ zu sehen, ist meiner Meinung nach schon ein klarer Nettovorteil gegenüber dem traditionellen Ansatz.