Helix Editor 25.07

• Helix 25.07 inclut le remplacement de composants cœur ainsi que l’ajout de nombreuses nouvelles fonctionnalités
• L’ergonomie et le workflow progressent fortement avec notamment l’explorateur de fichiers, l’affichage des couleurs de document LSP et les améliorations du mode commande
• Un nouveau crate, Tree-house, est introduit pour optimiser la coloration syntaxique et les requêtes
• Tree-house renforce considérablement la gestion des injections et des variables locales, ainsi que les performances et la maintenabilité
• Cette base ouvre la voie à une expérience multilangage plus large et plus rapide à l’avenir

---

Principales mises à jour de Helix 25.07

La sortie de Helix 25.07 réunit un remplacement très attendu de fonctionnalités cœur et l’ajout de diverses nouveautés. Cette version a vu la participation de 195 contributeurs. Helix est un éditeur de texte modal doté de sélections multiples, du LSP, de Tree-sitter et d’un support expérimental de DAP.

Nouvelles fonctionnalités majeures

Explorateur de fichiers

• La version 25.07 ajoute une fonctionnalité d’explorateur de fichiers accessible avec <space>e
• Cet explorateur propose une interface similaire à telescope
• Il facilite la navigation dans la structure hiérarchique des répertoires et offre un contrôle plus précis lors de l’exploration de gros projets

Affichage des couleurs de document LSP

• Helix peut désormais demander au serveur LSP les informations de couleur du document et afficher des plages de couleurs RGB en inline
• Avec des serveurs comme tailwindcss-language-server ou vscode-css-language-server, il est ainsi possible de voir directement dans le code des blocs de couleur correspondants

Améliorations du mode commande (:)

• Une réécriture complète du parsing des commandes et du code d’autocomplétion corrige des bugs et améliore l’usage
• Les commandes de la famille :write prennent désormais en charge des flags, comme --no-format
• Ajout de l’expansion de variables/valeurs dans les commandes (%{variable_name}, %sh{명령어}, etc.) ainsi que de l’autocomplétion
• La structure du parseur a été revue pour devenir extensible, ce qui facilitera les futures extensions des commandes et la gestion de valeurs d’entrée complexes

Tree-house : une nouvelle architecture d’intégration de Tree-sitter

Qu’est-ce que Tree-sitter ?

• Tree-sitter est un framework permettant de générer et d’utiliser des parseurs rapides et robustes face aux erreurs
• Les règles du parseur sont écrites dans une DSL grammaticale, puis utilisées pour générer et exploiter des arbres syntaxiques dans des éditeurs et outils
• On le retrouve par exemple dans l’exploration et la coloration du code sur GitHub, le spell-check de serveurs de code ou encore des outils de diff
• Les requêtes Tree-sitter servent à faire du pattern matching sur des sous-arbres et à capturer des nœuds syntaxiques

Intégration historique de Tree-sitter dans Helix et ses limites

• Aux débuts de Helix, l’intégration reposait sur les bindings Rust officiels (le crate tree-sitter) et le surligneur tree-sitter-highlight
• tree-sitter-highlight étant non incrémental, il fallait toujours reparser l’ensemble du document, avec à la clé une baisse de performances et un gaspillage de ressources
• Helix a tenté d’y remédier en forkant son propre surligneur, mais celui-ci est devenu de plus en plus complexe et difficile à maintenir

Adoption de Tree-house et bénéfices

• Tree-house met l’accent sur une architecture séparée pour le parsing et les requêtes, un code plus propre, la résolution de bugs persistants et une structure tournée vers l’avenir, notamment le parsing parallèle
• Son principal point fort est la gestion robuste des injections

Injections : prise en charge de plusieurs langages et couches

• Une injection consiste, par exemple, à parser séparément en Rust uniquement la portion d’un bloc de code Rust apparaissant dans un document Markdown
• Même des cas complexes, comme du Markdown dans un commentaire Rust, lui-même contenant un bloc Rust, sont gérés correctement grâce à une structure en arbre des couches

Injections incrémentales

• Seules les couches effectivement modifiées sont reparseées et réévaluées, ce qui limite le travail au strict minimum
• Cela maximise l’efficacité dans de très grands documents Markdown contenant de longues listes ou des structures imbriquées

Coloration des variables locales (lcals)

• Les variables locales, comme les paramètres de fonction, sont correctement surlignées dans leur portée de déclaration et de référence
• Tree-house résout ainsi un problème persistant où la coloration disparaissait lorsque la définition se trouvait hors de la zone visible

Prise en charge globalisée des injections

• Dans le type Syntax, la recherche et l’accès aux couches d’injection deviennent possibles en temps logarithmique
• Des API comme TreeCursor ou QueryIter permettent désormais d’appliquer cela à l’ensemble des couches d’injection
• Cela pose les bases d’un comportement cohérent aux frontières entre langages, comme dans du code au sein d’un <script> HTML ou dans des blocs de code Markdown

Conclusion

• Helix 25.07 combine une forte amélioration de l’ergonomie — avec l’explorateur de fichiers, l’affichage inline des couleurs et les progrès du mode commande/parseur — et l’introduction d’une nouvelle architecture basée sur Tree-house, ce qui en fait un candidat sérieux pour la prochaine génération d’éditeurs de texte
• Le détail des changements est disponible dans le changelog
• Il est possible de participer à la communauté et aux contributions via Matrix et le dépôt GitHub

[GN⁺]

Commentaires sur Hacker News

• Helix est vraiment excellent : le sélecteur de fichiers, la coloration syntaxique, le linting et bien d’autres fonctions sont disponibles immédiatement, sans installer de plugins ni faire de configuration complexe, alors que vim ou neovim demandent souvent beaucoup de réglages de base. J’aimerais l’utiliser, mais son principal défaut pour moi est que les raccourcis clavier ne fonctionnent pas comme dans vim. Je suis habitué depuis longtemps à des comportements comme x qui supprime le caractère sous le curseur ou d qui attend une action ensuite ; dès que ce n’est pas exactement ce comportement familier de vim, je me sens perdu et ça m’agace. Je pense que beaucoup d’utilisateurs de vim ressentent la même chose à ce sujet, et il est très difficile de changer ses habitudes, surtout quand vim est disponible partout par défaut, ce qui en fait un environnement dont on ne peut pas vraiment sortir. Heureusement, il existe un soft fork de Helix appelé evil-helix, qui ajoute les raccourcis Vim, et je voudrais le recommander à ceux qui ont la même gêne que moi. En plus, Helix et evil-helix fonctionnent très bien aussi sous Windows (cmd) en téléchargeant simplement l’exécutable .exe, sans avoir à installer Rust.

  • Pour moi, le problème n’est pas de ne pas vouloir apprendre quelque chose de nouveau, c’est plutôt que je ne peux pas réutiliser ces raccourcis ailleurs. Presque tous les éditeurs en ligne et environnements de travail proposent des raccourcis vim, et quand on se connecte en ssh sur Linux, il y a toujours vim, ce qui compte beaucoup. C’est un peu comme le clavier QWERTY : même s’il existe de meilleures dispositions, il est difficile d’abandonner cette résilience qui permet de s’adapter immédiatement à presque n’importe quel environnement.

  • Je n’ai aucun problème à apprendre de nouveaux outils. J’ai suffisamment utilisé Helix, mais le modèle nom-verbe m’a plutôt semblé moins bon, et le retour visuel devient au contraire une distraction quand on lit du code. Dans vim, on peut facilement faire des choses comme répéter simplement la dernière commande (avec le raccourci . par exemple), alors que dans Helix il faut y renoncer. La gestion d’état demande aussi plus d’attention que dans vim : avec vim, il suffit de suivre sa position actuelle dans le fichier, alors que dans Helix il faut aussi tenir compte d’où l’on était auparavant. Je veux un éditeur avec de bons réglages par défaut, une édition modale, et qui ne m’impose pas plus de synchronisation visuelle que nécessaire. Trop de synchronisation lui fait perdre ses qualités en tant que langage d’édition. Je préfère me concentrer sur la programmation, qui est plus intéressante que l’édition elle-même. Un éditeur qui demande davantage de concentration est en fait un moins bon éditeur.

  • Après avoir utilisé vim (neovim) pendant près de 20 ans, passer à helix n’a pas été difficile du tout, et je le préfère maintenant largement. J’ai ajusté quelques comportements modaux, mais je l’utilise en suivant la logique de helix. Les fonctions comme la multisélection ou le LSP sont fournies de base, et l’aide puissante qui affiche des indices sur les actions possibles pendant une saisie en plusieurs étapes est un gros avantage. Même s’il m’arrive encore d’utiliser du vim pur, et même si certaines associations ont changé dans ma tête, je me souviens des commandes de base et je peux me réajuster rapidement.

  • Helix est en train d’ajouter Scheme pour une configuration programmable. Avec cette programmabilité, il devrait devenir possible d’obtenir toutes sortes d’ajustements fins, comme le repeat / transient map d’emacs ou le suivi par état. Grâce à la révolution des LLMs, on vit dans un monde où il devient facile de toucher aussi à une 8e ou 9e langue, donc je pense que les outils offrant une configuration fine vont davantage émerger sur le marché.

  • Les raccourcis vim étaient l’unique raison pour laquelle je n’utilisais pas Helix. Si le support de vim est possible via un fork externe, je me dis que Helix officiel pourrait aussi le prendre en charge s’il le voulait ; alors est-ce un choix délibéré de ne pas le faire ?

• J’aime vraiment beaucoup Helix. Je le recommande vivement à ceux pour qui vim n’a jamais vraiment convenu, ou à ceux qui aiment le concept de vim sans avoir réussi à s’y adapter facilement. C’était bien plus facile à apprendre et à utiliser que les éditeurs de la famille vim existants, et sa configuration fournie par défaut est très pratique.

  • J’aime vraiment beaucoup Helix. Honnêtement, s’il ajoutait un peu plus de confort côté GUI, comme un explorateur de fichiers piloté à la souris, je pense qu’il pourrait devenir un concurrent sérieux de vscode.

• C’est agréable de voir qu’un éditeur doté de telles capacités reste minimaliste et ne se focalise pas sur des fonctions IA inutiles.

  • Discussion sur le minimalisme de Helix : https://github.com/helix-editor/helix/issues/6187

• Félicitations, j’espère que Helix réussira, mais j’ai le sentiment qu’il n’est pas fait pour moi. J’utilise Neovim et je peux faire presque tout ce que je veux avec, même si je n’en suis pas totalement satisfait. L’éditeur que je voudrais devrait répondre aux critères suivants :

  • codebase moderne, entièrement réécrite
  • raccourcis Vim ; cette mémoire musculaire est trop ancrée, donc je tiens au style Vim, sans me laisser convaincre qu’autre chose serait meilleur, et je veux que ça fonctionne exactement comme Vim
  • bons réglages par défaut ; Neovim a trop de configuration et les valeurs par défaut ne me satisfont pas toujours
  • basé sur Treesitter, et ce serait encore mieux si ça tournait sur WASM (comme Zed ou les versions récentes de Neovim)
  • système d’extension en Lua ; pas très fan de JS ou Scheme ; l’idéal serait un niveau où seuls les appels essentiels sont exposés via des modules WASM ; je voudrais un langage de configuration de plugins non Turing-complet
  • TUI avec GUI optionnelle
  • LSP, DAP, snippets, autocomplétion et UI de test/débogage intégrés
  • vue du système de fichiers intégrée, comme Oil.nvim
  • recherche intégrée dans le style Telescope/FZF-lua
  • intégration Git, et une UI git intégrée de type magit/neogit serait aussi bienvenue
  • manipulation d’AST basée sur Treesitter et sauts par labels intégrés, dans le style Flash.nvim
  • macros et multicurseurs
  • intégration IA optionnelle basée sur le curseur (UI de chat)

  • Moi aussi j’ai cette mémoire musculaire de Vim, mais je pense que beaucoup de gens s’y accrochent trop. J’ai changé plusieurs fois d’OS, d’éditeur et d’IDE, et pendant les premiers jours après chaque changement, c’est incroyablement frustrant, énervant, on a presque envie de tout laisser tomber et d’aller cultiver la terre ; puis cette période passe et une nouvelle mémoire musculaire finit toujours par se créer. Je trouve dommage de renoncer aux nombreux autres avantages d’un logiciel à cause de quelques jours d’inconfort.

  • Je ne vois pas clairement en quoi Helix ne satisferait pas les critères mentionnés ; à mes yeux, il semble en remplir presque tous.

  • Quand on lit cette liste d’exigences, on a surtout l’impression que ce qui est voulu au fond, c’est simplement Neovim avec autre chose que Lua.

• J’adore Helix, félicitations. Le thème par défaut est beau, la configuration de base est excellente, on peut l’utiliser immédiatement après l’installation sans réglages particuliers. Il n’a pas complètement remplacé mon IDE, mais j’ai mis un alias vi et défini $EDITOR sur Helix. Dès que j’ai besoin d’une correction rapide ou de déboguer quelque chose en CLI, j’utilise toujours Helix.

• J’aimais vraiment beaucoup Helix et j’étais très positif à son sujet, mais le comportement de l’undo ne me semblait pas logique, il annulait trop de choses à la fois et c’était peu naturel. À cause de ça, il m’est réellement arrivé de perdre du travail.

  • Deux points m’ont dérangé concernant l’undo :

    • quand le contenu modifié n’est pas visible à l’écran, l’éditeur saute bien à la bonne zone lors d’un undo, mais avec la même frappe il annule aussi immédiatement, ce qui est déroutant. Dans d’autres éditeurs, si le contenu n’est pas visible, on se contente de sauter à l’endroit sans annuler. Dans Helix, après une seule pression, il faut absolument vérifier si quelque chose a changé.
    • l’undo fonctionne par blocs trop gros. Même après avoir tapé pendant 30 minutes en mode insertion, tout est annulé d’un seul coup jusqu’au changement de mode. Il faut enregistrer soi-même des points de sauvegarde ; j’ai essayé d’en assigner un à la barre d’espace pour avoir un undo plus fin, mais cela provoque des effets secondaires comme la perte de la sélection. Je n’ai pas trouvé de solution propre. Je suis satisfait de Helix en général, mais c’est vraiment regrettable que la granularité de l’undo exige une intervention manuelle.

  • L’undo et le « répétition de la dernière commande » sont un peu étranges, mais le reste est très bon, donc j’utilise Helix comme éditeur principal. Par contre, concernant la partie où tu as perdu du travail, est-ce que le redo ne permettait pas de le récupérer ?

• J’aimerais qu’il existe un « mode Kakoune » dans Helix. Comme j’utilise Windows au travail, Kakoune n’est pas l’option idéale, donc Helix semblait parfait, mais j’ai du mal à dépasser la question des raccourcis. La philosophie des raccourcis de Helix me paraît plus verbeuse que la concision de Kakoune, et ça me gêne. En plus, la configuration des raccourcis dans Helix n’est pas assez puissante pour reproduire correctement Kakoune, ce qui est dommage. J’ai quitté vim pour Kakoune parce que j’étais déçu par les incohérences et comportements illogiques de vim, et sur ce point, Helix me donne l’impression d’un pas en arrière.

• L’expression « éditeur post-moderne » est amusante. C’est peut-être la deuxième meilleure blague depuis le « shell pour les années 90 » de Fish. En vidéo, c’est aussi impressionnant de voir qu’il est basé sur un TUI, avec un léger côté Emacs TUI.

• Il y a vraiment besoin d’un éditeur de type vim avec le niveau d’intégration tout-en-un de Helix. Les distributions Neovim assemblent leurs composants de manière trop lâche, et il y a toujours quelque chose de subtilement inconfortable. Je pense aussi que l’interface de Vim dans son ensemble aurait besoin d’être repensée, mais j’aimerais que le mode modal orienté action-objet soit conservé.

  • Evil-Helix semble correspondre à ce besoin. Ça a encore l’air assez brut par endroits, mais ça vaut la peine d’y jeter un œil : https://github.com/usagi-flow/evil-helix

  • Je me demande ce que signifie exactement le mode modal action-objet.

• J’ai trouvé impressionnante l’explication détaillée de la coloration syntaxique et des fonctions de compréhension du code dans Helix et les éditeurs similaires. La structure et les fonctionnalités basées sur tree-sitter semblent parfaitement adaptées à un langage de requête, et cela donne l’impression qu’au-delà de la recherche de symboles ou de références, un DSL de requête vraiment généraliste serait possible. Je me demande si ce genre de fonctionnalité existe déjà.

  • L’éditeur zed utilise tree-sitter et un moteur de requête puissant (le DSL est en Lisp Scheme). Référence : https://zed.dev/blog/syntax-aware-editing#tree-queries