Helix Editor 25.07

 (helix-editor.com)
1 Punkte von GN⁺ 2025-07-17 | 1 Kommentare | Auf WhatsApp teilen
  • Helix 25.07 umfasst den Austausch zentraler Komponenten sowie zahlreiche neue Funktionen
  • Mit Datei-Explorer, LSP-Dokumentfarbenanzeige und Verbesserungen im Command-Modus wurden Bedienbarkeit und Workflow deutlich verbessert
  • Für Syntax-Highlighting und Query-Optimierung wurde das neue Crate Tree-house eingeführt
  • Tree-house stärkt Injection- und Local-Verarbeitung sowie Performance und Wartbarkeit erheblich
  • Damit ist die Grundlage für künftig umfassendere Multisprachen-Erfahrung und Geschwindigkeitsverbesserungen gelegt

Wichtige Updates in Helix 25.07

Das Release Helix 25.07 besteht aus lange erwarteten Ersetzungen von Kernfunktionen und der Ergänzung verschiedener neuer Features. An dieser Version waren 195 Mitwirkende beteiligt. Helix ist ein modaler Texteditor mit Multi-Selection, LSP, Tree-sitter und experimenteller DAP-Unterstützung.

Neue Hauptfunktionen

Datei-Explorer

  • In 25.07 wurde die Funktion Datei-Explorer hinzugefügt, die über <space>e genutzt werden kann
  • Dieser Explorer bietet eine UI ähnlich wie telescope
  • Die hierarchische Navigation innerhalb von Verzeichnissen ist einfach, und bei der Navigation in großen Projekten ist eine präzisere Steuerung möglich

LSP-Dokumentfarbenanzeige

  • Helix kann nun LSP-Server nach Dokumentfarbinformationen fragen und RGB-Farbbereiche inline anzeigen
  • Zum Beispiel werden Farben von tailwindcss-language-server, vscode-css-language-server usw. übernommen, sodass Farbboxen direkt im Code visuell sichtbar sind

Verbesserungen im Command-Modus (:)

  • Durch eine vollständige Neuschreibung des Codes für Befehls-Parsing und Autovervollständigung wurden Bugs behoben und die Nutzbarkeit verbessert
  • Für Befehle der :write-Familie wurde Flag-Unterstützung wie etwa --no-format hinzugefügt
  • Funktionen zur Variablen-/Werterweiterung in Befehlen (%{variable_name}, %sh{명령어} usw.) sowie Autovervollständigung wurden eingeführt
  • Für die Verarbeitung komplexer Eingabewerte wurde die Struktur in einen erweiterbaren Parseraufbau geändert, was künftige Command-Erweiterungen erleichtert

Tree-house: Neue Struktur für die Tree-sitter-Integration

Was ist Tree-sitter?

  • Tree-sitter ist ein Framework zum Erzeugen und Nutzen schneller, fehlertoleranter Parser
  • Parserregeln werden in einer Grammatik-DSL geschrieben; in Editoren und Tools werden damit Syntaxbäume erzeugt und genutzt
  • Es wird beispielsweise für Code-Navigation und Highlighting bei GitHub, Spell-Check auf Code-Servern oder in Diff-Tools verwendet
  • Tree-sitter-Queries werden für Pattern-Matching auf Teilbäumen und zum Erfassen von Syntaxknoten genutzt

Bisherige Tree-sitter-Anbindung in Helix und ihre Probleme

  • In den Anfangszeiten von Helix wurden die offiziellen Rust-Bindings (das tree-sitter-Crate) und der Highlighter tree-sitter-highlight genutzt
  • tree-sitter-highlight arbeitet nicht inkrementell, sodass stets das gesamte Dokument neu geparst werden musste, was zu Performanceverlusten und Ressourcenverschwendung führte
  • Helix forkte den Highlighter zur Verbesserung selbst, doch mit wachsender Komplexität wurde die Wartung zunehmend schwierig

Einführung und Vorteile von Tree-house

  • Tree-house legt den Fokus auf eine getrennte Parsing-/Query-Struktur, sauberen Code, das Beenden langjähriger Bugs und eine zukunftsorientierte Architektur wie etwa paralleles Parsing
  • Die zentrale Stärke ist die robuste Verarbeitung von Injection

Injection: Unterstützung für mehrere Sprachen/Layer

  • Injection bedeutet zum Beispiel, dass bei einem Rust-Codeblock in Markdown nur dieser Bereich separat als Rust geparst wird
  • Auch komplexe Fälle, etwa Markdown in Rust-Kommentaren und darin wiederum Rust-Codeblöcke, werden durch die Verwaltung der Layer als Baumstruktur präzise unterstützt

Inkrementelle Injection

  • Nur Layer, in denen tatsächlich Änderungen auftreten, werden schnell neu geparst und Queries erneut ausgeführt, sodass nur die minimal nötige Arbeitseinheit genutzt wird
  • Das maximiert die Effizienz bei Markdown-Dokumenten mit sehr großen Listen oder verschachtelten Strukturen

Highlighting lokaler Variablen (lcals)

  • Lokale Variablen wie etwa Parameter innerhalb von Funktionen werden im Bereich ihrer Deklaration und Referenzen (Scope) präzise hervorgehoben
  • Ein langjähriges Problem, bei dem Highlighting verschwand, wenn sich die Definition außerhalb des sichtbaren Bereichs befand, wurde in Tree-house gelöst

Verallgemeinerte Injection-Unterstützung

  • Im Typ Syntax wird das Suchen und Abfragen von Injection-Layern in logarithmischer Zeit möglich
  • Über APIs wie TreeCursor und QueryIter kann die Anwendung auf sämtliche Injection-Layer ausgeweitet werden
  • Damit ist die Grundlage für konsistentes Verhalten über Sprachgrenzen hinweg geschaffen, etwa für Code in HTML-<script> oder Markdown-Codeblöcken

Abschluss

  • Helix 25.07 bringt mit Datei-Explorer, Color-Inlays und Verbesserungen an Command-Modus und Parsern eine spürbare Usability-Erneuerung und steigt zugleich mit der neuen Tree-house-Architektur zu einem Kandidaten der nächsten Generation von Texteditoren auf
  • Detaillierte Update-Inhalte finden sich im changelog
  • Beteiligung an Community und Beiträgen ist über Matrix und das GitHub-Repository möglich

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-07-17
Hacker News-Kommentare

  • Helix ist wirklich großartig: Dateiauswahl, Syntax-Highlighting, Linting und viele weitere Funktionen sind sofort verfügbar, ganz ohne Plugin-Installation oder komplizierte Konfiguration, während vim oder neovim standardmäßig viel Einrichtung brauchen. Ich würde es gern nutzen, aber der größte Nachteil ist für mich, dass die Keybindings anders funktionieren als in vim. Wenn das vertraute x nicht das Zeichen unter dem Cursor löscht oder d nicht auf eine weitere Aktion wartet, wie ich es aus jahrelanger vim-Nutzung gewohnt bin, verwirrt und frustriert mich das. Vermutlich empfinden viele vim-Nutzer hier ähnlich, und solche Gewohnheiten zu ändern ist sehr schwer, zumal vim praktisch überall standardmäßig vorhanden ist, sodass man dieser Umgebung nicht entkommt. Zum Glück gibt es mit evil-helix einen Soft Fork von Helix, der Vim-Keybindings hinzufügt; den würde ich allen empfehlen, die dasselbe Problem haben wie ich. Außerdem laufen Helix und evil-helix unter Windows (cmd) auch ohne Rust-Installation direkt, wenn man einfach die .exe herunterlädt.

    • Für mich geht es nicht darum, nichts Neues lernen zu wollen, sondern darum, dass ich diese Keybindings anderswo nicht nutzen kann. Fast alle Online-Editoren und Workstations bieten Vim-Keybindings an, und wenn man sich per ssh auf Linux verbindet, ist vim immer da. Das ist wie mit der QWERTY-Tastatur: Selbst wenn es bessere Layouts gibt, möchte ich die Flexibilität nicht aufgeben, mich in fast jeder Umgebung sofort zurechtzufinden.

    • Ich habe überhaupt kein Problem damit, neue Tools zu lernen. Ich habe Helix ausführlich ausprobiert, aber das Nomen-Verb-Modell erscheint mir eher schlechter, und das visuelle Feedback stört beim Lesen von Code eher. In vim lassen sich Dinge wie das einfache Wiederholen des letzten Befehls (.-Binding usw.) bequem erledigen, bei Helix muss man darauf eher verzichten. Auch das Zustandsmanagement verlangt mehr Aufmerksamkeit als bei vim: Bei vim muss ich nur meine aktuelle Position in der Datei im Blick behalten, bei Helix auch noch, wo ich vorher war. Ich will Standardkonfiguration, modales Editing und einen Editor, der nicht mehr visuelle Synchronisation aufzwingt als nötig. Wenn es zu viel Synchronisation gibt, verliert man die Vorteile eines Bearbeitungssystems als Sprache. Ich möchte mich auf das Programmieren konzentrieren, das interessanter ist als das Editieren selbst. Ein Editor, der mehr Konzentration verlangt, ist als Editor eher schlechter.

    • Als ich nach fast 20 Jahren mit vim(neovim) zu helix gewechselt bin, war das überhaupt nicht schwer, und inzwischen bevorzuge ich es deutlich. Ich habe zwar einige modale Verhaltensweisen angepasst, nutze es aber weiterhin nach der Logik von helix. Funktionen wie Mehrfachauswahl oder LSP sind standardmäßig enthalten, und die starke Hilfe, die bei mehrstufigen Eingaben mögliche Aktionen als Hinweise anzeigt, ist ein großer Vorteil. Auch wenn ich gelegentlich reines vim benutze, kann ich grundlegende Befehle schnell wieder abrufen, selbst wenn sich einige Zuordnungen in meinem Kopf verändert haben.

    • Helix arbeitet derzeit daran, Scheme für programmierbare Konfiguration hinzuzufügen. Wenn diese Programmierbarkeit kommt, werden voraussichtlich viele Feinabstimmungen möglich sein, die man heute aus emacs kennt, etwa repeat/transient map oder zustandsbezogenes Tracking. Dank der LLM-Revolution leben wir in einer Welt, in der man auch eine 8. oder 9. Sprache leicht anfassen kann; deshalb glaube ich, dass Werkzeuge mit fein abstimmbarer Konfiguration am Markt stärker aufsteigen werden.

    • Vim-Keybindings waren der einzige Grund, warum ich Helix nicht benutze. Wenn Vim-Unterstützung über einen externen Fork möglich ist, dann könnte Helix das offiziell wohl auch unterstützen, wenn es wollte; daher frage ich mich, ob man sich bewusst dagegen entscheidet.

  • Ich mag Helix wirklich sehr und kann es Leuten, die mit vim nie warm geworden sind oder das vim-Konzept mögen, sich aber nur schwer daran gewöhnen konnten, nur dringend empfehlen. Es war viel leichter zu lernen und zu benutzen als bisherige vim-artige Editoren, und die mitgelieferte Standardkonfiguration ist sehr praktisch.

    • Ich mag Helix wirklich sehr. Ehrlich gesagt denke ich, dass es mit etwas mehr Komfort in der GUI, etwa einem mausgestützten Dateibrowser, ein starker Konkurrent für vscode sein könnte.

  • Es ist schön zu sehen, dass ein Editor mit so starken Fähigkeiten weiterhin minimalistisch bleibt und sich nicht auf nutzlose AI-Funktionen konzentriert.

  • Glückwunsch, ich hoffe, Helix hat Erfolg, aber für mich passt es nicht ganz. Ich benutze Neovim und kann damit fast alles machen, was ich will. Ganz zufrieden bin ich aber auch nicht. Mein idealer Editor hätte ungefähr diese Eigenschaften:

    • moderne Codebasis, komplett neu geschrieben
    • Vim-Keybindings; dieses Muskelgedächtnis ist stark, deshalb halte ich an Vim fest, lasse mich nicht von Behauptungen abbringen, etwas anderes sei besser, und will, dass es wirklich wie Vim funktioniert
    • gute Defaults; Neovim hat zu viele Einstellungen und die Standardwerte sind nicht immer zufriedenstellend
    • Tree-sitter-basiert, idealerweise auch auf WASM lauffähig (wie Zed, aktuelles Neovim)
    • Erweiterungssystem in Lua; JS und Scheme eher nicht, idealerweise WASM-Module mit nur den nötigen exponierten Funktionen; für die Plugin-Konfiguration gern eine nicht-Turing-vollständige Konfigurationssprache
    • TUI und optionale GUI
    • eingebautes LSP, DAP, Snippets, Autovervollständigung sowie Test-/Debugging-UI
    • eingebaute Dateisystemansicht wie Oil.nvim
    • eingebaute Suche im Stil von Telescope/FZF-lua
    • Git-Integration, gern auch eingebaute Git-UI wie magit/neogit
    • eingebaute Tree-sitter-basierte AST-Manipulation und Label-Jumps im Stil von Flash.nvim
    • Makros und Multi-Cursor
    • optionale cursor-basierte AI-Integration (Chat-UI)

    • Ich erkenne das Vim-Muskelgedächtnis auch an, aber ich glaube, viele Leute verbeißen sich zu sehr darin. Ich habe OS, Editoren und IDEs mehrfach gewechselt, und in den ersten Tagen ist das jedes Mal extrem frustrierend und macht einen fast wahnsinnig, aber danach entsteht immer ein neues Muskelgedächtnis. Es wäre schade, wegen ein paar unbequemer Tage auf die vielen anderen Vorteile einer Software zu verzichten.

    • Mir ist nicht ganz klar, in welchem Punkt Helix die genannten Bedingungen nicht erfüllt; aus meiner Sicht deckt Helix fast alles davon ab.

    • Wenn man sich die Anforderungen ansieht, wirkt es letztlich so, als würde man bei Neovim nur Lua durch eine andere Sprache ersetzen wollen.

  • Ich liebe Helix, Glückwunsch. Das Standard-Theme ist hübsch, die Default-Konfiguration hervorragend, und nach der Installation kann man sofort loslegen, ohne viel einrichten zu müssen. Es hat meine IDE zwar nicht vollständig ersetzt, aber ich habe vi darauf aliasiert und $EDITOR ebenfalls auf Helix gesetzt. Wenn ich in der CLI schnell etwas ändern oder debuggen muss, greife ich inzwischen immer zu Helix.

  • Ich mochte Helix wirklich sehr, aber das Undo-Verhalten wirkte auf mich nicht logisch und oft unnatürlich, etwa wenn zu viel auf einmal rückgängig gemacht wird. Dadurch habe ich tatsächlich schon Arbeit verloren.

    • Beim Undo haben mich zwei Dinge gestört:

      • Wenn der bearbeitete Inhalt beim Undo nicht auf dem Bildschirm ist, springt der Editor zwar zuverlässig dorthin, macht mit demselben Tastendruck aber sofort auch das Undo, was verwirrend ist. Andere Editoren springen in so einem Fall nur dorthin und machen noch kein Undo. Bei Helix muss man nach einem Tastendruck immer erst prüfen, ob sich schon etwas geändert hat.
      • Undo erfolgt in zu groben Blöcken. Selbst wenn man 30 Minuten im Insert-Modus tippt, wird erst beim Moduswechsel alles auf einmal rückgängig gemacht. Savepoints muss man manuell setzen; ich habe versucht, das auf die Leertaste zu legen, um feineres Undo zu bekommen, aber dann gibt es Nebenwirkungen wie verlorene Auswahlen. Ich habe dafür keine saubere Lösung gefunden. Mit Helix selbst bin ich zufrieden, aber dass die Undo-Tiefe direkte Eingriffe verlangt, ist wirklich schade.

    • Undo und „letzten Befehl wiederholen“ sind etwas seltsam, aber die übrigen Funktionen sind so gut, dass ich Helix trotzdem als Haupteditor nutze. Bei dem verlorenen Arbeitsstand frage ich mich allerdings, ob Redo danach wirklich nicht mehr möglich war.

  • Ich hoffe, es gibt irgendwann einen „Kakoune-Modus“ für Helix. Da ich bei der Arbeit Windows nutze, ist Kakoune nicht optimal, und Helix schien perfekt zu sein, aber ich komme über die Keybindings nicht hinweg. Die Philosophie der Keybindings in Helix ist wortreicher als die Prägnanz von Kakoune, und genau das stört mich. Außerdem ist die Keybinding-Konfiguration von Helix nicht mächtig genug, um Kakoune wirklich nachzubilden, was ich schade finde. Ich bin von vim zu Kakoune gewechselt, weil mich die Inkonsistenzen und unlogischen Verhaltensweisen von vim enttäuscht haben, und in diesem Punkt wirkt Helix für mich wie ein Schritt zurück.

  • Die Bezeichnung „postmoderner“ Editor ist lustig; seit der Beschreibung der Fish-Shell als „Shell für die 90er“ vermutlich der zweitbeste Witz. Im Video fand ich beeindruckend, dass er TUI-basiert ist, und er hat noch ein wenig das Gefühl von Emacs TUI.

  • Es gibt wirklich Bedarf an einem vim-ähnlichen Editor mit der integrierten Geschlossenheit von Helix. Bei Neovim-Distributionen sind die einzelnen Bausteine zu locker gekoppelt, sodass sich immer etwas subtil unangenehm anfühlt. Ich denke auch, dass die Vim-Oberfläche insgesamt neu gestaltet werden müsste, aber die aktions-objektzentrierte Modalität sollte erhalten bleiben.

    • Evil-Helix scheint genau zu solchen Anforderungen zu passen. Es wirkt zwar noch ziemlich rau, aber einen Blick ist es wert: https://github.com/usagi-flow/evil-helix

    • Ich frage mich, was mit einer Action-Object-Modalität gemeint ist.

  • Die detaillierte Erklärung zu Syntax-Highlighting und Codeverständnis in Helix und ähnlichen Editoren war beeindruckend. Die auf tree-sitter basierende Struktur und Funktionalität scheint sehr gut zu einer Query-Sprache zu passen, und über Symbolsuche oder Referenzfindung hinaus wirkt ein allgemeines Query-DSL möglich. Ich frage mich, ob es solche Funktionen bereits gibt.