Ki Editor - Un éditeur fonctionnant sur une base AST

 (ki-editor.org)
2 points par GN⁺ 2026-03-08 | 1 commentaires | Partager sur WhatsApp
  • Éditeur structurel à curseurs multiples permettant de manipuler directement la structure du code, avec un fonctionnement centré sur l’arbre syntaxique (AST)
  • Prend en charge une interaction au niveau des nœuds syntaxiques, ce qui réduit l’écart entre l’intention d’écriture du code et l’action d’édition réelle
  • Grâce à la fonction de curseurs multiples, il est possible de modifier ou refactoriser plusieurs nœuds syntaxiques en même temps, ce qui améliore l’efficacité des modifications à grande échelle
  • Redéfinit l’édition modale afin de permettre des déplacements cohérents entre différentes unités, comme les mots, les lignes ou les nœuds syntaxiques
  • Renforce la précision et la cohérence de l’édition de code, en proposant un nouveau paradigme d’édition qui améliore la productivité des développeurs

Présentation de Ki Editor

  • Ki Editor est un éditeur structurel à curseurs multiples (Multi-cursor structural editor) qui propose un environnement d’édition manipulant directement la structure syntaxique du code
  • Contrairement à l’édition textuelle traditionnelle, il manipule les éléments du code à partir de l’arbre syntaxique (AST)
  • Il permet une édition directe au niveau des nœuds syntaxiques sans combinaison complexe de clavier ni recours à la souris

Interaction avec les nœuds syntaxiques

  • La fonctionnalité First-class syntax node interaction permet de manipuler directement la structure syntaxique du code
    • Elle vise à réduire l’écart entre l’intention d’écriture du code et l’action d’édition réelle
    • Elle permet des manipulations au niveau syntaxique sans déplacement de souris ni saisies clavier complexes

Fonction de curseurs multiples

  • Les multiple cursors permettent d’éditer simultanément plusieurs nœuds syntaxiques
    • La manipulation parallèle de nœuds syntaxiques améliore l’efficacité des modifications massives et du refactoring
    • Les tâches répétitives de modification de code peuvent ainsi être traitées rapidement

Redéfinition de l’édition modale

  • La fonctionnalité Redefine modal editing standardise le mode de sélection
    • Elle prend en charge de manière cohérente les déplacements entre différentes unités comme les mots, les lignes et les nœuds syntaxiques
    • Elle renforce la souplesse et la cohérence par rapport à l’édition modale classique

Importance

  • Ki Editor propose une expérience d’édition centrée sur la structure syntaxique, ce qui améliore la précision lors de l’écriture et de la modification du code
  • En combinant curseurs multiples et manipulation de nœuds syntaxiques, il présente une nouvelle approche de l’édition de code qui contribue à améliorer la productivité des développeurs

À lire aussi

1 commentaires

 
GN⁺ 2026-03-08
Avis sur Hacker News

  • En voyant la fonctionnalité « First-class syntactic selection », j’ai tout de suite pensé aux raccourcis Expand / Shrink Selection que j’utilise souvent dans les IDE JetBrains
    Avec Ctrl + W et Ctrl + Shift + W, on peut étendre ou réduire la sélection par unité syntaxique
    Cette fonctionnalité a complètement changé ma façon de voir l’interaction avec le « texte » d’un fichier
    VS Code et Zed ont des fonctions similaires, mais j’ai l’impression que l’extension/réduction y est trop grossière
    Lien vers la documentation JetBrains

    • Voici les raccourcis JetBrains que j’utilise souvent
      Avec Cmd+Shift+V, on ouvre le presse-papiers en pile pour rechercher ou choisir parmi les éléments copiés auparavant
      Cmd+Shift+E affiche la liste des emplacements récents, et Cmd+Shift+A ouvre la palette d’actions pour faire une recherche floue sur toutes les commandes
      Il y a aussi la fonction Local History, qui permet de suivre l’historique des modifications d’un fichier bien plus finement que Git
      Ce genre de fonctions mène naturellement à l’idée de pouvoir « modifier directement depuis le buffer de résultats de recherche »
    • Dans Neovim aussi, on peut utiliser la même idée avec incremental selection basé sur tree-sitter
    • Mathematica proposait déjà l’extension de sélection avec Alt+. au début des années 90
      Un double-clic sélectionnait un mot, un triple-clic l’ensemble des arguments d’une fonction, et quatre clics sélectionnaient tout f(a,r,g,s) : la taille de l’unité syntaxique augmentait selon le nombre de clics
      J’en ai encore la mémoire musculaire
    • Je fais des recherches sur le versioning basé sur l’AST
      J’expérimente l’idée de faire fonctionner les commits, diff et cherry-pick par unités syntaxiques, comme avec Ctrl+W
      C’est résumé dans le projet librdx
    • J’utilise souvent cette fonction dans helix aussi, mais l’implémentation de vscode ne me plaît pas
      L’édition consciente de l’AST rappelle la commodité des langages de la famille Lisp
      En Lisp, des choses faisables par simple manipulation de listes demandent en JS un LSP ou un parseur séparé
      Quand je repasse à TypeScript après avoir utilisé Clojure le week-end, les commandes paredit me manquent vraiment

  • J’ai déjà fabriqué moi-même un éditeur basé sur un arbre syntaxique
    Comme on manipule uniquement l’arbre au lieu de saisir du texte, un programme syntaxiquement invalide ne peut tout simplement pas exister
    En revanche, le grand défi était d’en faire un mode de saisie réellement utilisable
    Je ne peux plus l’exécuter aujourd’hui faute du matériel d’affichage de l’époque, mais j’ai conservé une description du projet

    • Le problème, c’est la contrainte selon laquelle « le chemin qui mène d’un programme A à un programme B doit toujours passer par des programmes valides »
      Cela impose parfois des chemins peu intuitifs, voire l’obligation de tout réécrire depuis le début
      Il peut même exister des structures valides dont aucun chemin de génération n’existe
    • J’ai déjà utilisé en entreprise un langage expérimental et son éditeur basés sur JetBrains MPS
      C’était intéressant en théorie, mais j’ai eu l’impression d’une impasse peu pratique
      Il est difficile de battre l’universalité et la simplicité d’une interface textuelle
      Entre l’éditeur dédié, un nouveau système de versioning, la rupture avec l’écosystème, etc., les contraintes concrètes sont trop nombreuses
      Comme les humains ne pensent pas en unités arborescentes, devoir coder uniquement dans un état syntaxiquement correct en permanence était une expérience extrêmement frustrante
      Au final, ce sont les outils qui autorisent une rigueur flexible (par ex. le typage progressif de TypeScript) qui survivent réellement
    • Si vous voulez revivre ces anciens systèmes, vous pouvez recréer un environnement VT11 avec les émulateurs simh et mame
      Voir simh, mame, code VT11, documentation
    • Un projet appelé Pantograph retente cette idée dans une version moderne
      Ce n’est pas encore un éditeur généraliste, mais l’orientation autour de l’extension de plage de sélection d’arbre semble prometteuse
      Lien vers Pantograph
    • Je développe actuellement un projet successeur appelé BABLR
      Il est construit sur un système de parsing capable de manipuler des arbres valides mais incomplets
      Grâce à une représentation des trous comme <//>, on peut manipuler en toute sécurité une syntaxe incomplète
      Exemple : 2 + · peut être parsé en arbre <BinaryExpression>
      Si ça vous intéresse, on en discute sur la communauté Discord

  • Je ne suis pas habitué à l’édition AST
    J’utilise tout au plus des objets texte pour manipuler les arguments de fonction ou les arglists
    Côté LSP, je me limite surtout à aller à la définition et au renommage
    Au final, ça me motive surtout à améliorer davantage ma maîtrise de l’éditeur

    • Dans ce cas, un outil comme ast-grep est utile
      On peut écrire des motifs avec une syntaxe très proche du code et voir les transformations directement sous les yeux
      Par exemple, on peut faire une transformation vers l’optional chaining avec ast-grep -pattern '$A && $A.$B' --rewrite '$A?.$B' -lang ts
      Les métavariables comme $X, $A, etc. imposent une correspondance sur le même nœud
      Les agents de codage IA n’utilisent pas encore très bien ce genre de motifs, mais l’outil lui-même est très solide
    • En pratique, il n’est pas nécessaire de comprendre en profondeur la structure AST
      Le plus souvent, il suffit de sélectionner un nœud syntaxique puis le supprimer, le copier ou le remplacer
    • Les besoins en édition AST varient selon le travail de chacun
      Je ne fais pas souvent de gros refactorings, donc je ne ressens pas vraiment le besoin de l’apprendre
      Mais un développeur travaillant sur un grand service pourrait avoir un avis totalement différent
    • Je suis dans une position similaire
      Apprendre à écrire des macros en Elixir m’a apporté beaucoup d’intuitions, et Lisp va dans le même sens
      Les approches diffèrent selon les langages, mais au fond elles mènent toutes vers la même destination

  • Voici comment je classe les éditeurs

    1. Orthodoxes (Orthodox) — centrés sur l’UI et l’intégration
    2. Modaux (amélioration de Vim) — conservent les keybindings existants
    3. Modaux (nouvelle approche) — réinterprètent la philosophie de Vim
      Ki appartient à la troisième catégorie, et je garde toujours ce type de projet à l’œil
    • Il y a aussi une 4e catégorie — Emacs qui englobe tout
    • Je pense pareil. Il y a eu beaucoup de challengers, mais j’ai toujours l’impression qu’il n’y a qu’un seul champion
    • Moi aussi, je développe un éditeur de code modal basé sur l’AST
      Les nœuds de l’UI ressemblent à du texte ordinaire, mais ce sont en réalité des structures arborescentes
      Si vous voulez donner un premier avis, contactez-moi à l’adresse mail de mon profil
    • Si on continue à “améliorer Vim”, on finit par arriver à la blague : « Ed Visual Mode Improved Improved »

  • La difficulté de l’édition AST, c’est la discoverability
    On voit les nœuds à l’écran, mais on ne connaît souvent pas leur nom
    Je réfléchis donc à un plugin qui entourerait la zone autour du curseur avec des couleurs pour visualiser chaque portée (scope)
    L’idée serait de penser en termes de « aller au prochain bleu » plutôt que « aller à la fonction suivante »

    • Dans Ki, même sans connaître le nom d’un nœud, on peut appuyer sur d m pour afficher les labels de tous les nœuds syntaxiques actuellement visibles et s’y déplacer directement
    • Malgré tout, des fonctions plus générales de sélection/réduction au niveau AST restent précieuses
      Des opérations comme sélectionner l’intérieur ou l’extérieur du nœud courant sont utiles

  • J’ai créé une intégration Ki pour VSCode
    Je regrette de ne pas avoir pu y contribuer davantage ensuite, mais je pense que ce genre d’innovation dans les outils fondamentaux est très important
    Lien vers l’extension Ki pour VSCode

    • Oui, c’est bien cette extension
    • Essayer un nouvel éditeur est intimidant, et l’extension VSCode réduit la barrière à l’entrée

  • Avant de voir les exemples, je ne voyais pas trop l’intérêt,
    mais dans la « First-class syntactic modification », le fait que les virgules soient ajoutées/supprimées automatiquement m’a impressionné
    La logique d’implémentation me semble même plutôt simple
    Maintenant, j’aimerais essayer une intégration Ki dans Zed ou des rewrites basés sur l’AST

    • C’est moi qui ai créé l’extension VSCode de Ki, et comme elle utilise une architecture de communication WebSocket, l’intégration à Zed devrait être assez simple
      Il suffit de se référer au code du dépôt Ki

  • Je vais probablement l’essayer moi-même bientôt
    J’aime bien le fait que ce soit indépendant de la disposition du clavier
    Je trouve aussi intéressant que cela s’inspire de la philosophie d’Emacs selon laquelle « tout est un buffer modifiable »
    Bien sûr, chaque éditeur implique de gros trade-offs, donc il faut l’essayer pour se faire une idée

    • La structure de l’éditeur étant conçue autour du modèle d’édition, c’est dommage qu’il faille tout reconstruire à chaque fois
      Neovim est excellent, mais son modèle d’édition a ses limites
      S’il avait eu une architecture totalement remplaçable, Helix ou Ki n’auraient peut-être jamais été nécessaires
    • En revanche, pour moi, cette indépendance vis-à-vis de la disposition a été un cauchemar
      En le lançant avec un clavier Dvorak, toutes les correspondances étaient complètement cassées
      Quand un logiciel croit être plus intelligent que son utilisateur, cela finit au contraire par lui donner un sentiment d’impuissance

  • Bien sûr, Emacs l’a déjà
    Le paquet combobulate en est un exemple

    • Avec combobulate, on obtient une navigation AST aussi naturelle que l’édition Lisp
      On peut supprimer un nœud avec M-k ou rechercher/modifier directement avec des requêtes tree-sitter
      L’intégration est déjà excellente, mais un éditeur dédié à l’AST pourrait encore faire progresser l’UX

  • C’est une fonctionnalité qui colle vraiment très bien au workflow de Helix
    On a l’impression que la dernière pièce du schéma classique déplacement → action vient enfin de se mettre en place