Helix : l’éditeur de texte postmoderne

• Helix est un éditeur de texte modal basé sur le terminal, un projet open source qui intègre des fonctionnalités modernes
• Grâce à l’intégration de Tree-sitter, il offre des fonctions d’édition conscientes de la syntaxe comme la coloration syntaxique, le calcul de l’indentation et la navigation dans le code
• Il prend en charge le Language Server Protocol pour fournir des fonctionnalités de niveau IDE comme l’autocomplétion, l’accès à la définition, la consultation de la documentation et les diagnostics
• Écrit en Rust, il fonctionne sans Electron ni JavaScript et peut être utilisé efficacement dans des environnements SSH·tmux·terminal
• Le système de plugins et le frontend GUI sont prévus pour plus tard, avec comme caractéristiques une base de code légère et une configuration moderne par défaut

---

Caractéristiques principales

• Helix utilise comme unité d’édition centrale un système de multi-sélection et de curseurs inspiré de Kakoune
  • Les commandes manipulent plusieurs zones sélectionnées simultanément, ce qui permet une édition de code en parallèle
• Il utilise Tree-sitter pour générer des arbres syntaxiques tolérants aux erreurs
  • Cela permet une coloration syntaxique précise, une indentation automatique et des fonctions de navigation dans le code

Manipulation et navigation dans le code

• Il fournit des fonctions de sélection et de déplacement par nœuds de l’arbre syntaxique pour les fonctions, classes, commentaires, etc.
  • Cela permet une édition basée sur la structure syntaxique, et non sur le simple texte
• Via le Language Server Protocol (LSP), il offre selon le langage des fonctions d’autocomplétion, d’accès à la définition, de consultation de la documentation et de diagnostics
  • Des fonctionnalités de niveau IDE sont ainsi disponibles dans le terminal sans configuration supplémentaire

Fondations techniques

• Écrit en Rust, il garantit stabilité et performances
  • Il n’utilise ni Electron, ni VimScript, ni JavaScript
  • Il peut fonctionner dans des environnements SSH, tmux et terminal classique
  • Sa structure légère améliore l’efficacité énergétique

Fonctionnalités modernes intégrées

• Un fuzzy finder permet d’explorer les fichiers et symboles, ainsi que d’effectuer une recherche à l’échelle du projet
• Il intègre diverses fonctions pratiques comme la fermeture automatique des parenthèses, l’intégration de surround et la personnalisation des thèmes
• Sa structure offre une riche intégration des fonctions de base sans plugin séparé

Questions fréquentes

• L’expression « postmoderne » est une plaisanterie signifiant que si Neovim est un « Vim moderne », alors Helix appartient à la génération suivante
• Un frontend GUI est prévu à l’avenir sous la forme d’un prototype basé sur WebGPU
• Le système de plugins n’est actuellement pas implémenté, mais son introduction est prévue plus tard
• Par rapport à Kakoune, Helix intègre davantage de fonctionnalités et utilise une analyse du code basée sur Tree-sitter
• Contrairement à Vim, Helix a été conçu de zéro, avec une base de code réduite et des valeurs par défaut modernes nécessitant très peu d’ajustements de configuration

Communauté et participation

• Il est possible de contribuer au code sur GitHub
• Les discussions autour du projet ont lieu sur le canal Matrix
• Le développement peut être soutenu via OpenCollective

[GN⁺]

Réactions sur Hacker News

• La blague autour de « Post-modern?! » m’a intrigué
  Beaucoup d’ingénieurs comprennent « postmodern » simplement comme l’étape suivant modern, alors que ce n’est pas son sens d’origine dans les arts et les sciences humaines
  Bien sûr, cet usage n’est pas un gros problème, mais ça m’a quand même frappé, car je m’attendais à une vraie créativité « postmoderne »

  • Quelqu’un disait que Thiel et Luckey avaient mal compris Tolkien ; j’aimerais bien voir des exemples précis
  • J’ai eu exactement la même réaction la première fois que j’ai vu la blague de Helix
    Mais comme le « postmodernism » est à l’origine un concept né en réaction au modernisme, l’interprétation comme simple « après modern » n’est pas totalement fausse non plus, à mon avis
    Cela dit, avec le temps, le sens est devenu bien plus complexe, et c’est aussi drôle qu’aujourd’hui ça donne une impression de « dated af »
    « Helix, le premier éditeur qui ne croit pas aux grands récits. Helix, l’éditeur relativiste. Helix, avec les dernières mises à jour Foucault et Derrida intégrées »
  • Tout est de la faute de Perl. C’est eux qui ont lancé ce genre de nomenclature

• J’utilise Helix comme éditeur principal depuis plusieurs années (Sublime → Atom → Vim → Helix)
  La plupart des LSP fonctionnent quasiment sans configuration, et le fichier de config est bien plus concis qu’un ancien .vimrc
  Il ne m’a fallu que quelques jours pour changer ma mémoire musculaire de Vim, mais j’ai toujours des sentiments mitigés à propos des éditeurs modaux
  J’attends encore la fonctionnalité de pliage de code

  • Comme j’utilise à la fois Emacs et Vim, je me demande ce qui gêne dans l’édition modale
    Sur Emacs, on peut avoir une édition très puissante sans mode modal avec multiple cursors et des plugins basés sur treesitter
    Je me demande si le mode modal de Helix te gêne pour des raisons similaires
  • Mon reproche, ça reste la touche Escape
    Sur les anciens claviers Unix, elle était près de la rangée de repos, mais aujourd’hui elle est beaucoup trop loin
    La plupart des tutoriels ne mentionnent même pas les touches alternatives, donc je ne comprends toujours pas pourquoi plus de la moitié des utilisateurs continuent à utiliser Escape telle quelle

• J’ai réessayé Helix il y a quelques jours, et le fait de ne pouvoir utiliser l’IA que via le LSP me va, mais
  le fait qu’il ne recharge pas automatiquement quand un fichier change à l’extérieur était beaucoup trop pénible
  Je me retrouvais sans arrêt à me demander si le fichier modifié par l’IA était bien à jour

  • GitHub Copilot, Claude Code et Codex modifient directement les fichiers via une API d’IDE et fournissent aussi une vue diff
    Cette approche est bien plus fiable et séduisante
    À l’inverse, certains outils IA disent qu’« un IDE n’est pas nécessaire » et misent sur le CLI ; pour moi c’est complètement n’importe quoi
  • Ce n’est pas une solution parfaite, mais Helix a les commandes :reload et :reload-all
    Moi, j’ai associé reload-all à Ctrl-r
  • Ça peut se corriger avec un patch simple → lien vers la PR GitHub
  • J’ai eu le même problème, puis j’ai changé de workflow : surveillance des changements de fichiers avec lazygit, et modifications uniquement dans Helix
    Une autre option, c’est mux, qui permet de commenter les changements proposés par un LLM ligne par ligne ou bloc par bloc (c’est encore au début)
  • Avec le temps, j’en suis presque venu à préférer l’absence de rechargement automatique
    Quand je travaille avec Claude Code, j’aime bien que les fichiers ne changent pas automatiquement sous mes yeux

• Vim, c’est le C, Helix le C++, et Ki Editor fait penser à Rust
  Helix a hérité de beaucoup d’idées de Vim, mais manque de cohérence dans les raccourcis clavier, et les combinaisons conceptuelles sont moins fortes
  Par exemple, dans les buffers on se déplace avec k, mais dans l’explorateur de fichiers il faut utiliser ctrl+n

  • Je suis curieux de savoir pourquoi Ki ferait penser à Rust. Je trouve aussi que Helix est déjà un éditeur très réussi
  • Je suis surpris d’apprendre que Helix a maintenant un explorateur de fichiers. C’est justement son absence qui m’avait fait l’écarter
  • On voit quelque chose de similaire dans Vim aussi. Dans la fenêtre d’autocomplétion, k sert de caractère saisi, donc il faut utiliser une autre touche
    J’imagine que c’est la même raison dans Helix
  • Le concept de raccourcis basés sur la position des touches ne me convainc pas
    Je me demande ce que ça donne en SSH quand la disposition du clavier change
  • Dire que « Helix, c’est du C++ » me paraît être une métaphore exagérée. Si Vim est le C, alors Neovim est plus proche du C++

• J’avais vraiment envie d’aimer Helix
  Les réglages par défaut sont bons, et j’ai volontairement abandonné certaines habitudes Vim pour l’apprendre, mais
  j’en suis finalement arrivé à la conclusion que les raccourcis clavier sont un compromis fait pour simplifier l’implémentation
  Aujourd’hui, je reviens à Neovim pour les petites retouches et à Zed (en mode vim) pour les gros travaux

  • Tu as essayé Ki Editor ? Du point de vue UX, c’est un modèle plus avancé que Helix
  • En tant qu’utilisateur de Vim de longue date, le design trop prescriptif de Helix m’a dérangé
    Par exemple, quand on rouvre un fichier, le curseur ne revient pas à sa dernière position
    J’aurais pu le modifier avec un LLM, mais je n’avais pas envie de maintenir un fork de Helix
  • Il existe aussi evil-helix, une version avec les raccourcis Vim. Ça vaut peut-être le coup d’essayer
  • Ce sont justement les raccourcis différents de Vim qui m’ont fait abandonner au final
    Il est vraiment difficile de renoncer à une mémoire musculaire accumulée pendant des années
  • Je ne suis pas d’accord avec l’idée que l’UI de Helix n’est pas simple
    Pour moi, la combinaison hx + Zed fonctionne très bien

• Comme Helix ne prend pas en charge la mise à jour live des fichiers, il est peu pratique à utiliser avec des agents de code

• Je recommande de lire la deuxième question de la FAQ de Helix
  Le LSP Python fonctionnait immédiatement, sans configuration, ce qui m’a impressionné
  Mais avec 25 ans de mémoire musculaire Vim, les petites différences de Helix sont vraiment déroutantes
  Au final, le problème, ce n’est pas Helix, c’est ma mémoire musculaire

  • Après avoir longtemps utilisé un clavier ergonomique, revenir à un clavier standard était difficile au début, mais au bout du compte on finit par s’habituer aux deux
    Je pense que ça peut être pareil avec Vim et Helix
  • Dans Emacs, on peut associer M-ESC ESC à une commande inoffensive pour éviter le problème des fenêtres qui se ferment
    Exemple : (global-set-key (kbd "M-ESC ESC") 'keyboard-quit)
  • Tu as essayé le mode Evil d’Emacs ? J’ai pu passer depuis Vim presque sans friction
  • J’ai moi aussi utilisé Vim pendant 25 ans, mais je suis complètement passé à Helix
    Une fois qu’on s’habitue à des différences comme dd ou G, on l’apprécie de plus en plus
  • Zed conserve la philosophie de Helix (prise en charge LSP par défaut) tout en offrant des raccourcis vi exacts

• J’utilise Helix comme éditeur par défaut depuis quelques années
  J’apprécie particulièrement sa simplicité, sa rapidité, sa navigation centrée clavier, et son intégration du LSP Elixir

• J’utilise Helix en principal et j’ai déployé beaucoup de code avec
  Mon fichier de config fait moins de 50 lignes, et j’y ai juste ajouté quelques touches Vim
  Passer de Vim à Helix et inversement ne me pose pas de gros problème
  Ma config est ici

• J’ai créé directement dans VS Code une extension de mode modal, et l’approche de Kakoune et Helix m’avait paru intéressante
  Le fait de « montrer à l’avance ce qui va être modifié » et la conception centrée sur les multi-curseurs me semblaient pertinents
  Mais après quelques semaines, je suis finalement revenu au style Vim classique
  L’approche multi-curseur n’était utile que lorsqu’on pouvait voir tous les changements à l’écran
  Ces derniers temps, grâce à l’IA, j’écris plus de texte que de code, donc j’ai l’impression que la valeur de ce mode d’édition a diminué

  • Emacs a la commande mc-hide-unmatched-lines, qui permet de n’afficher que les lignes avec un curseur
    Les multi-curseurs sont bien pour des modifications courtes et simples, mais pour des changements complexes, les outils d’édition par lots sont plus efficaces
  • La fonctionnalité Reveal Cursors de Ki Editor a été créée
    pour résoudre le problème des curseurs hors écran
  • Le simple fait de pouvoir « voir tous les changements d’un coup d’œil » me semble déjà être un bénéfice net par rapport à l’approche classique