Ki Editor – ein AST-basierter Editor

 (ki-editor.org)
2 Punkte von GN⁺ 2026-03-08 | 1 Kommentare | Auf WhatsApp teilen
  • Ein struktureller Editor auf Basis mehrerer Cursor, mit dem sich die Codestruktur direkt manipulieren lässt und der sich am Syntaxbaum (AST) orientiert
  • Unterstützt Interaktionen auf Syntaxknoten-Ebene, wodurch die Lücke zwischen der beabsichtigten Codeerstellung und der tatsächlichen Bearbeitung verringert wird
  • Mit der Mehrfach-Cursor-Funktion lassen sich mehrere Syntaxknoten gleichzeitig ändern oder refaktorieren, was die Effizienz bei umfangreichen Bearbeitungen erhöht
  • Definiert den modusbasierten Bearbeitungsansatz neu, sodass Bewegungen über Wörter, Zeilen, Syntaxknoten und andere Einheiten hinweg auf konsistente Weise möglich sind
  • Stärkt Präzision und Konsistenz bei der Codebearbeitung und präsentiert ein neues Bearbeitungsparadigma zur Steigerung der Produktivität von Entwicklerinnen und Entwicklern

Überblick über Ki Editor

  • Ki Editor ist ein Multi-cursor structural editor, der eine Bearbeitungsumgebung bietet, in der sich die syntaktische Struktur von Code direkt handhaben lässt
  • Im Unterschied zur traditionellen textbasierten Bearbeitung werden Codeelemente auf Basis des Syntaxbaums (AST) manipuliert
  • Direktes Bearbeiten auf Syntaxknoten-Ebene ist ohne Maus oder Tastenkombinationen möglich

Interaktion mit Syntaxknoten

  • Über die Funktion First-class syntax node interaction wird die syntaktische Struktur des Codes direkt behandelt
    • Der Fokus liegt darauf, die Lücke zwischen der beabsichtigten Codeerstellung und dem tatsächlichen Bearbeitungsverhalten zu verringern
    • Manipulation auf Syntax-Ebene erfolgt ohne Mausbewegungen oder komplexe Tasteneingaben

Mehrfach-Cursor-Funktion

  • Mit Multiple cursors können mehrere Syntaxknoten gleichzeitig bearbeitet werden
    • Parallele Manipulation von Syntaxknoten verbessert die Effizienz bei Massenbearbeitungen und Refactoring
    • Wiederkehrende Codeänderungen lassen sich schnell erledigen

Neudefinition des modusbasierten Editierens

  • Die Funktion Redefine modal editing standardisiert den Auswahlmodus
    • Bewegungen über Wörter, Zeilen, Syntaxknoten und andere Einheiten hinweg werden auf konsistente Weise unterstützt
    • Gegenüber bestehender modusbasierten Bearbeitung werden Flexibilität und Konsistenz verbessert

Bedeutung

  • Ki Editor bietet ein an der Syntaxstruktur orientiertes Bearbeitungserlebnis und erhöht dadurch die Genauigkeit beim Schreiben und Ändern von Code
  • Durch die Kombination aus Mehrfach-Cursor und Syntaxknoten-Manipulation wird ein neuer Ansatz für die Codebearbeitung vorgestellt, der zur Steigerung der Entwicklerproduktivität beiträgt

Verwandte Beiträge

1 Kommentare

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

  • Als ich die Funktion „First-class syntactic selection“ gesehen habe, musste ich sofort an die Tastenkürzel Expand / Shrink Selection in JetBrains-IDs denken
    Mit Ctrl + W und Ctrl + Shift + W kann man die Auswahl nach syntaktischen Einheiten erweitern oder verkleinern
    Diese Funktion hat meine Sicht auf die Art und Weise, wie man mit dem „Text“ einer Datei interagiert, komplett verändert
    In VS Code oder Zed gibt es ähnliche Funktionen, aber dort fühlt sich das Erweitern/Verkleinern zu grob an
    Link zur JetBrains-Dokumentation

    • Die JetBrains-Tastenkürzel, die ich oft benutze, sind die folgenden
      Mit Cmd+Shift+V öffnet man die Zwischenablage-Historie und kann frühere Kopien durchsuchen oder auswählen
      Cmd+Shift+E zeigt die Liste der zuletzt besuchten Stellen, und Cmd+Shift+A öffnet die Action-Palette, in der man alle Befehle per Fuzzy Search finden kann
      Außerdem kann man mit Local History Dateiänderungen viel feiner als mit Git nachverfolgen
      Solche Funktionen führen dann zu Konzepten wie dem „direkten Bearbeiten im Suchergebnis-Puffer“
    • In Neovim kann man dieselbe Funktion mit tree-sitter-basiertem incremental selection nutzen
    • Mathematica bot schon Anfang der 90er mit Alt+. eine Funktion zum Erweitern der Auswahl
      Doppelklick wählte ein Wort, Dreifachklick alle Funktionsargumente und vier Klicks den gesamten Ausdruck f(a,r,g,s) aus — also eine Struktur, bei der mit der Anzahl der Klicks die syntaktische Einheit wächst
      Dieses Muskelgedächtnis habe ich bis heute
    • Ich forsche gerade an AST-basierter Versionsverwaltung
      Ich experimentiere mit der Idee, Commits, Diffs und Cherry-Picks ebenfalls wie mit Ctrl+W auf syntaktischer Ebene arbeiten zu lassen
      Mehr dazu steht im librdx-Projekt
    • Ich nutze diese Funktion auch in helix oft, aber die Implementierung in vscode gefällt mir nicht
      AST-bewusstes Editieren erinnert mich an den Komfort von Lisp-artigen Sprachen
      In Lisp kann man Dinge mit einfacher Listenmanipulation erledigen, für die man in JS ein LSP oder einen separaten Parser braucht
      Wenn ich am Wochenende Clojure benutzt habe und dann wieder zu TypeScript zurückkehre, vermisse ich die paredit-Befehle wirklich

  • Ich habe früher einmal selbst einen syntaxbaum-basierten Editor gebaut
    Weil man statt Text nur den Baum bearbeitet, kann kein syntaktisch fehlerhaftes Programm existieren
    Allerdings war es eine große Herausforderung, daraus eine in der Praxis nutzbare Eingabemethode zu machen
    Heute kann ich ihn nicht mehr ausführen, weil ich die damalige Display-Hardware nicht mehr habe, aber die Projektbeschreibung ist erhalten

    • Das Problem ist die Einschränkung, dass „der Weg von Programm A zu B immer über gültige Programme führen muss“
      Dadurch muss man teils unintuitive Wege gehen oder in manchen Fällen sogar ganz von vorn anfangen
      Es sind sogar Strukturen möglich, die zwar gültig sind, für die aber kein Erzeugungspfad existiert
    • Wir haben früher in der Firma mit einer experimentellen Sprache und einem Editor auf Basis von JetBrains MPS gearbeitet
      Theoretisch interessant, aber ich hatte das Gefühl, dass es praktisch eine Sackgasse ist
      Gegen die Allgemeingültigkeit und Einfachheit textbasierter Interfaces kommt man nur schwer an
      Eigener Editor, neue Versionsverwaltung, abgeschnittenes Ökosystem und andere praktische Einschränkungen sind einfach zu groß
      Menschen denken nicht in Baumstrukturen, deshalb war es extrem frustrierend, nur in stets syntaktisch korrekten Zuständen programmieren zu können
      Am Ende überleben eher Werkzeuge, die flexible Strenge erlauben, etwa das schrittweise Typisieren in TypeScript
    • Wer das alte System noch einmal erleben möchte, kann mit den Emulatoren simh und mame eine VT11-Umgebung nachbilden
      Siehe dazu simh, mame, VT11-Code und Dokumentation
    • Ein Projekt namens Pantograph versucht diese Idee gerade in moderner Form noch einmal
      Es ist noch kein allgemeiner Editor, aber die Richtung mit erweiterbaren Baum-Auswahlbereichen wirkt vielversprechend
      Pantograph-Link
    • Ich entwickle gerade ein Nachfolgeprojekt namens BABLR
      Es baut auf einem Parser-System auf, das unvollständige, aber gültige Bäume verarbeiten kann
      Mit Gap-Darstellungen wie <//> lässt sich unvollständige Syntax sicher behandeln
      Beispiel: 2 + · kann als <BinaryExpression>-Baum geparst werden
      Wer Interesse hat, kann in der Discord-Community mitdiskutieren

  • Ich bin an AST-Editing nicht gewöhnt
    Ich nutze höchstens Textobjekte für Funktionsargumente oder Arglisten
    Von LSP-Funktionen verwende ich im Wesentlichen nur „Gehe zur Definition“ und „Umbenennen“
    Am Ende motiviert mich das vor allem dazu, meine Editor-Fähigkeiten weiter auszubauen

    • In solchen Fällen ist ein Tool wie ast-grep nützlich
      Man kann Muster in einer Syntax schreiben, die fast wie echter Code aussieht, und die Umwandlung direkt vor Augen sehen
      Zum Beispiel ist mit ast-grep -pattern '$A && $A.$B' --rewrite '$A?.$B' -lang ts eine Optional-Chaining-Transformation möglich
      Metavariablen wie $X oder $A erzwingen dabei das Matching desselben Knotens
      KI-Coding-Agenten nutzen solche Muster bisher noch nicht gut, aber das Tool selbst ist sehr solide
    • In der Praxis muss man die AST-Struktur gar nicht tief verstehen
      Meist reicht es, syntaktische Knoten auszuwählen und dann zu löschen, zu kopieren oder zu ersetzen
    • Je nach Arbeit unterscheiden sich auch die Anforderungen an AST-Editing
      Ich mache nicht oft große Refactorings und habe daher nicht das Gefühl, dass ich es unbedingt lernen muss
      Für Entwickler großer Services kann das aber völlig anders aussehen
    • Ich sehe das ähnlich
      Als ich in Elixir gelernt habe, Makros zu schreiben, habe ich viele Einsichten gewonnen; bei Lisp ist es ähnlich
      Die Ansätze unterscheiden sich je nach Sprache, aber letztlich führen sie zum selben Ziel

  • So teile ich Editoren ein

    1. orthodox — Fokus auf UI und Integration
    2. modal (Vim-Verbesserung) — bestehende Keybindings bleiben erhalten
    3. modal (neuer Ansatz) — die Vim-Philosophie wird neu interpretiert
      Ki gehört zur dritten Kategorie, und ich beobachte solche Projekte fortlaufend
    • Es gibt auch eine vierte Kategorie — Emacs, das alles umfasst
    • Ich denke genauso. Es gab viele Herausforderer, aber gefühlt gibt es immer noch nur einen Champion
    • Ich entwickle ebenfalls einen AST-basierten modalen Code-Editor
      Die UI-Knoten sehen wie normaler Text aus, sind aber in Wirklichkeit Baumstrukturen
      Wer frühes Feedback geben möchte, kann sich über die E-Mail in meinem Profil melden
    • Bei „Vim verbessert“ fällt einem am Ende fast schon der Witz ein: „Ed Visual Mode Improved Improved“

  • Die Schwierigkeit bei AST-Editing ist die Discoverability
    Man sieht die Dinge auf dem Bildschirm, kennt aber oft den Namen des Knotens nicht
    Deshalb denke ich über ein Plugin nach, das den Bereich um den Cursor farblich markiert und so die jeweiligen Scopes visualisiert
    Statt „zur nächsten Funktion springen“ würde man dann eher in Kategorien wie „zum nächsten blauen Bereich“ denken

    • In Ki kann man auch ohne Kenntnis der Knotennamen mit d m die Labels aller aktuell sichtbaren syntaktischen Knoten einblenden und direkt dorthin springen
    • Trotzdem bleibt eine allgemeine AST-Auswahl- und Schrumpf-/Erweiterungsfunktion sehr wertvoll
      Operationen wie das Auswählen innerhalb oder außerhalb des aktuellen Knotens sind nützlich

  • Ich habe eine Ki-Integration für VSCode gebaut
    Danach konnte ich leider nicht mehr viel dazu beitragen, aber ich halte solche grundlegenden Innovationen bei Werkzeugen für sehr wichtig
    Link zur Ki-VSCode-Erweiterung

    • Genau, das ist die Erweiterung
    • Es ist abschreckend, gleich einen neuen Editor auszuprobieren, aber die VSCode-Erweiterung senkt die Einstiegshürde

  • Vor den Beispielen war ich mir nicht sicher,
    aber als ich bei „First-class syntactic modification“ gesehen habe, dass Kommata automatisch hinzugefügt und entfernt werden, war ich beeindruckt
    Auch die Implementierungslogik scheint eher simpel zu sein
    Jetzt möchte ich in Zed ebenfalls eine Ki-Integration oder AST-basierte Rewrites ausprobieren

    • Ich habe die VSCode-Erweiterung für Ki gebaut, und weil sie auf einer WebSocket-Kommunikationsstruktur basiert, dürfte sich das auch in Zed leicht anbinden lassen
      Der Code im Ki-Repository sollte dafür als Referenz reichen

  • Ich werde es bald selbst ausprobieren
    Mir gefällt, dass es unabhängig vom Tastaturlayout sein soll
    Interessant ist auch, dass es von der Emacs-Philosophie „alles ist ein bearbeitbarer Buffer“ inspiriert ist
    Natürlich sind die Trade-offs bei jedem Editor groß, daher muss man es wohl selbst testen

    • Schade ist, dass der Editor um das Editiermodell herum entworfen ist und man deshalb jedes Mal alles neu bauen muss
      Neovim ist großartig, aber sein Editiermodell hat Grenzen
      Wenn die Struktur vollständig austauschbar wäre, bräuchte man vielleicht weder Helix noch Ki
    • Für mich war diese Layout-Unabhängigkeit allerdings ein Albtraum
      Als ich es mit einer Dvorak-Tastatur ausprobiert habe, waren die Mappings komplett kaputt
      Wenn Software glaubt, klüger zu sein als der Nutzer, führt das eher dazu, dass der Nutzer sich ohnmächtig fühlt

  • Natürlich gibt es das in Emacs längst
    Das Paket combobulate ist ein Beispiel dafür

    • Mit combobulate ist AST-Navigation so natürlich wie Lisp-Editing
      Mit M-k kann man Knoten löschen, und über tree-sitter-Queries kann man direkt suchen und bearbeiten
      Die Integration ist schon jetzt hervorragend, aber ein reiner AST-Editor hätte beim UX noch Spielraum nach oben

  • Das passt wirklich hervorragend in den Helix-Workflow
    Es fühlt sich an, als würde beim bestehenden Muster Bewegung → Aktion nun das letzte Puzzleteil einrasten