Retour d’expérience après être passé de Vim à Helix

 (jvns.ca)
11 points par GN⁺ 2025-10-11 | 2 commentaires | Partager sur WhatsApp
  • Un développeur qui utilisait Vim depuis 20 ans partage son expérience après être passé à l’éditeur Helix et l’avoir utilisé pendant 3 mois
  • Helix est séduisant car il prend en charge nativement les serveurs de langage (LSP) sans configuration complexe
  • Par rapport à Vim/Neovim, ses excellentes fonctions de recherche et ses curseurs multiples sont particulièrement améliorés, ce qui facilite la compréhension du contexte dans plusieurs fichiers et les modifications en masse
  • Lors de la saisie, une fenêtre de référence rapide (quick reference) permet d’utiliser les raccourcis sans les oublier
  • Malgré quelques inconvénients — absence de génération automatique des listes Markdown, pas d’undo persistant, crash environ une fois par semaine — l’expérience globale reste très satisfaisante
  • Réapprendre 20 ans de mémoire musculaire accumulée avec Vim s’est révélé plus facile que prévu, et il a été bien plus efficace de ne pas chercher à imposer les habitudes de Vim mais d’apprendre la “méthode Helix”

Pourquoi passer à Helix

  • L’auteur a commencé à utiliser Helix pour profiter facilement de ses fonctions intégrées de serveur de langage
    • Dans Vim/Neovim, configurer un serveur de langage était complexe, alors qu’avec Helix il est possible, sans réglage supplémentaire, de naviguer vers les définitions ou de renommer des symboles immédiatement
    • Auparavant, il fallait maintenir de nombreux plugins et fichiers de configuration, tandis qu’Helix réduit cette charge grâce à sa prise en charge native

Les principaux atouts de Helix

  • La qualité du système de recherche
    • Lors d’une recherche de chaîne dans tout le dépôt, les résultats s’affichent dans une fenêtre d’aperçu, ce qui permet de faire défiler les fichiers correspondants et de voir en même temps le code autour
    • Contrairement au plugin ripgrep de Vim, les résultats offrent beaucoup plus de contexte, ce qui permet de juger rapidement
  • La fonction de référence rapide pour les raccourcis
    • En appuyant sur la touche g, une fenêtre d’aide affiche la liste des commandes de déplacement disponibles, ce qui est intuitif
    • Même les raccourcis peu utilisés restent faciles à retrouver, ce qui adoucit la courbe d’apprentissage

Différences entre Vim et Helix

  • Pour les marques, au lieu de ma et 'a, Helix utilise Ctrl+O et Ctrl+I pour suivre l’historique des déplacements du curseur
  • À la place des macros, on utilise surtout l’édition à curseurs multiples
    • Pour des modifications globales dans un document : sélection complète avec % → sélection par expression régulière avec s → exécution des modifications multiples nécessaires
    • Les curseurs multiples sont bien plus pratiques que d’écrire une macro à chaque fois
  • À la place des onglets, on peut basculer rapidement via le sélecteur de buffers avec space + b

Les points gênants de Helix

  • La fonction de reflow du texte est moins efficace que gq dans Vim
    • Elle s’accorde mal avec les listes
  • Pas de génération automatique des listes Markdown
    • Même en appuyant sur "Entrée" à la fin d’un élément de liste, la liste ne se poursuit pas
    • Il existe une solution partielle pour les listes à puces, mais pas pour les listes numérotées
  • La fonction d’undo persistant n’est pas encore implémentée
    • Dans Vim, undofile permettait d’annuler des modifications même après avoir quitté l’éditeur, mais Helix ne propose pas encore cette fonction
  • Pas de rechargement automatique des fichiers
    • Après modification d’un fichier sur le disque, il faut exécuter manuellement :reload-all (:ra<tab>)
  • Des crashs occasionnels
    • Environ une fois par semaine, peut-être liés à une édition intensive de Markdown
    • Il suffit de rouvrir l’éditeur, donc ce n’est pas un gros problème
  • Malgré cela, l’auteur continue d’utiliser Helix

Le processus de transition et l’apprentissage

  • Il craignait que réapprendre 20 ans de mémoire musculaire Vim soit très difficile
  • Il a commencé à utiliser Helix sur un projet annexe pendant ses vacances, et au bout d’une à deux semaines, cela n’était déjà plus déroutant
  • Au début, il a essayé d’imposer des raccourcis proches de Vim, sans succès, et apprendre la “méthode Helix” s’est révélé bien plus simple
  • Certaines choses restent toutefois déroutantes
    • Le w de Vim et le w de Helix n’ont pas la même définition d’un « mot » (dans Helix, l’espace après le mot est inclus, dans Vim non)

Un environnement d’édition basé sur le terminal

  • Comme il utilisait principalement les versions GUI de vim/neovim depuis des années, utiliser un éditeur dans le terminal a demandé une petite adaptation
  • Workflow finalement adopté
    • Une fenêtre de terminal distincte pour chaque projet, avec tous les onglets de cette fenêtre partageant le même répertoire de travail
    • L’onglet Helix placé en premier dans la fenêtre du terminal
  • Cela facilite le travail parallèle sur plusieurs projets, au point d’être peut-être meilleur que son workflow précédent

Configuration

  • Par rapport à une configuration Neovim qui faisait des centaines de lignes, il conserve une configuration très simple
    • Il ne configure essentiellement que 4 raccourcis clavier
  • Principaux éléments de configuration
    • Thème : solarized_light
    • Le registre de yank par défaut est défini sur + afin de le synchroniser avec le presse-papiers système
    • # est configuré comme raccourci pour activer/désactiver les commentaires (il n’aimait pas le Ctrl+C par défaut)
    • ^ et $ sont remappés pour aller au début/à la fin de la ligne (il ne voulait pas apprendre une autre méthode)
    • <space>l est configuré sur :reflow (comme il écrit beaucoup de texte, il a souvent besoin de reflow et regrettait le raccourci gq de Vim)
  • Un fichier de configuration languages.toml séparé sert à définir des préférences par langage
    • Pour Python : formateur black, serveur de langage pyright, formatage automatique désactivé

Conclusion : impressions après 3 mois

  • Trois mois, ce n’est pas si long, et un retour à Vim reste possible un jour
    • Il avait déjà migré vers nix avant de revenir à Homebrew 8 mois plus tard (même s’il utilise toujours NixOS pour administrer un serveur et en est satisfait)
  • Helix n’est pas encore totalement abouti, mais sa direction vers un “éditeur sans configuration” est claire
  • Grâce à sa simplicité et à ses fonctions intégrées, il a le potentiel de remplacer Vim à long terme
  • La poursuite de son adoption dépendra toutefois des progrès en stabilité et de l’élargissement des fonctionnalités

À lire aussi

2 commentaires

 
GN⁺ 2025-10-11
Avis Hacker News
  • L’éditeur plante parfois avec un segfault environ une fois par semaine, mais ça ne me dérange pas vraiment ; cette approche de la perte de données consistant à simplement rouvrir l’application me semble étonnante, d’autant plus que Helix n’a pas de persistent undo, donc rouvrir ne restaure pas l’état précédent
    J’utilise Vim/Neovim depuis longtemps, j’ai essayé des configurations personnalisées comme des configurations toutes faites, et même si j’aime vraiment Vim, le fait que Helix soit immédiatement utilisable sans travail de configuration séparé est extrêmement séduisant
    Cela dit, la config de Helix elle-même me paraît très rudimentaire, si bien que je me dis qu’après seulement quelques premières années sur Vim, j’aurais probablement pu reproduire dans Vim l’environnement que j’obtiens avec Helix, et dire ainsi que je n’étais plus en enfer de configuration
    J’adore les pop-ups d’aide qui indiquent le chemin à suivre ou les raccourcis à utiliser ; je n’emploie pas si souvent des fonctions comme « aller à la définition » ou « aller aux références », donc j’oublie facilement les raccourcis ; j’aimerais que ce type de pop-up contextuel soit adopté partout, et s’il apparaissait intelligemment seulement quand on hésite à taper, ce serait vraiment utile
    • Avoir des pop-ups d’aide contextuelle pour les combinaisons de touches complexes dans toutes les applis serait incroyablement pratique, surtout si elles s’affichaient intelligemment uniquement quand la saisie s’interrompt
      J’utilise Vim/Neovim depuis 20 ans, mais ce n’est qu’il y a 6 mois que j’ai installé le plugin which-key, et je le trouve extrêmement utile
      which-key.nvim GitHub
    • J’ai l’impression qu’on passe à côté du contexte du problème de configuration dans Vim
      J’ai essayé à plusieurs reprises de mettre en place correctement la configuration du serveur de langage principal, par exemple pour avoir « aller à la définition », mais j’ai trouvé bien trop difficile d’obtenir un environnement agréable dans Vim ou Neovim
    • Je suis d’accord sur le fait qu’on peut reproduire la configuration de Vim, mais le fait de pouvoir installer Helix directement sur un serveur et s’en servir tout de suite est très pratique
      Pas besoin de s’embêter à déplacer sa config Vim et toutes les dépendances associées ; l’environnement de développement paraît bien plus portable, même s’il reste plus basique qu’une configuration Vim complexe
    • Je suis d’accord à 100 % sur la fonction de pop-up d’aide ; si ce genre de fonction était appliqué à davantage d’endroits, ce serait extrêmement utile
      Surtout, après avoir vu les explications et les captures d’écran correspondantes dans l’article, je me suis mis à la désirer très fortement
      Si le pop-up apparaissait intelligemment selon des conditions comme un timeout, ce serait excellent : pas gênant quand on n’en a pas besoin, mais une aide automatique dès qu’on hésite
    • J’utilise Helix presque tous les jours depuis 3 ans, et les plantages par segfault sont suffisamment rares pour se compter sur les doigts d’une main, c’est quasiment inexistant
  • Je suis complètement accro à Helix et je l’utilise pour tout mon développement
    Avant, j’utilisais surtout neovim et VS Code, mais Helix comble un avantage particulier
    • Le design est magnifique (énorme souci du détail)
    • Les performances sont rapides (je ne l’ai jamais trouvé lent)
    • Les raccourcis par défaut sont ergonomiques et naturels à l’usage
    • On peut l’utiliser immédiatement après l’installation, sans configuration
      J’en avais assez de configurer neovim ou de continuer à utiliser vim, et j’avais besoin d’un point intermédiaire entre VS Code et nvim ; Helix tombe exactement juste
      Si j’avais été un maître de vimscript, j’aurais peut-être réfléchi autrement, mais comme ce n’est pas le cas, c’est parfait pour moi
      J’aimerais que Helix reste comme il est, sans chercher à devenir plus modulaire ni plus UNIX-like
      Il existe déjà tout un écosystème d’outils, et on peut aussi l’utiliser avec Claude Code, avec rafraîchissement du buffer pour appliquer les nouvelles modifications
      C’est l’un des meilleurs éditeurs, au point que j’ai commencé à soutenir le projet chaque mois
      Si je devais souhaiter une évolution, ce qui me manque le plus serait le rendu d’images ou de formules dans l’éditeur ; j’espère que ce point pourra être implémenté via le protocole terminal de Kitty ou des plugins comme sixel
      J’aimerais particulièrement en profiter pour travailler sur des notes ou un blog en fichiers Markdown
      Longue vie à Helix
    • Les applis comme Helix, utilisables dès l’installation, sont très rassurantes car elles réduisent les inquiétudes liées aux supply chain attacks
      Avec VSCode ou (neo)vim, il faut récupérer des plugins depuis plusieurs endroits, et ça m’a toujours mis mal à l’aise
    • Si on a besoin d’un intermédiaire entre nvim et vscode, on peut se demander pourquoi ne pas simplement utiliser le plugin vim dans vscode
    • J’aime aussi helix, mais je n’abandonnerai pas nvim
      Je ne suis pas développeur Lua, mais les LLM aident énormément à configurer ou modifier nvim
      La raison principale qui m’a amené vers helix, c’est que la configuration LSP/lint y est vraiment très bien faite
    • Au lieu de parler de « maître de vimscript », certains font remarquer qu’en réalité, avec neovim, il faut plutôt utiliser Lua
  • J’ai essayé pendant quelques semaines de passer de neovim à helix, mais j’ai noté qu’il manquait encore des fonctions essentielles
    • Actions de code automatiques à l’enregistrement, par exemple ajout des imports Go : PR #6486
    • Recherche floue couplée à un sélecteur de fichiers comme telescope+rg : PR #11285
    • Mise à jour automatique du buffer lors de modifications du fichier sur disque : issue #1125
    • Fonction de navigateur d’arborescence de fichiers : refusée dans le cadre du système de plugins, pas encore implémentée PR #5768 Il y avait aussi d’autres petits points acceptables, donc je pense réessayer dans 1 ou 2 ans
    • J’utilise Helix en compilant souvent depuis HEAD avec homebrew, donc je suis surpris que Julia dise qu’il y a souvent des crashs
      Je partage quelques points sur des fonctions déjà mergées dans HEAD —

      Actions de code à l’enregistrement : cela peut être résolu avec des hooks à l’enregistrement, au moins pour Go, même si c’est peut-être plus difficile pour d’autres langages
      Recherche floue : elle est intégrée depuis très longtemps et a été grandement améliorée par une refonte récente
      Mise à jour automatique du buffer : c’est une fonction indispensable quand on laisse fréquemment l’éditeur en arrière-plan
      Arborescence de fichiers : dans HEAD, on peut faire une exploration hiérarchique avec Space+e/E, ajout relativement récent

    • Le navigateur de fichiers lié a été abandonné, mais un explorateur de style vim-telescope a été mergé dans Helix au début de cette année
      Comme il existe déjà un sélecteur de fichiers intégré basé sur la recherche floue, un explorateur de fichiers classique n’apporte pas énormément d’utilité supplémentaire
    • J’ai moi aussi essayé de passer de neovim à helix, mais à cause de la mémoire musculaire acquise pendant des décennies avec les commandes vim, les petites erreurs se sont accumulées et j’ai vite abandonné
      J’ai également essayé un plugin de raccourcis vim pour Helix, mais il ne correspondait que partiellement, ce qui a rendu la déception encore plus grande
    • Je trouve dommage que Helix ne détecte pas automatiquement les modifications de fichiers faites par des programmes externes, comme templ ou sqlc, pour recharger le fichier
      Je me demande comment les utilisateurs expérimentés de Helix règlent ce problème
  • Si je me suis mis à utiliser Helix, c’est principalement à cause du processus de configuration des serveurs de langage (LSP)
    Configurer confortablement des serveurs de langage dans Vim/Neovim était devenu trop pénible, donc je suis passé à Helix
    Cela dit, ces 5 dernières années, des distributions Neovim « batteries incluses » sont apparues, rendant la configuration très facile
    Je suis d’accord pour dire que beaucoup de développeurs ne veulent pas passer leur temps à déboguer leur éditeur, et je pense que c’est pour cela que JetBrains est populaire
    En revanche, l’idée qu’un utilisateur de Neovim depuis 20 ans n’ait jamais réussi à mettre en place correctement un environnement LSP me semble un peu difficile à croire, et je me demande si c’est vraiment une expérience honnête de l’auteur
    • Il existe des cas où, même après plus de 10 ans sur Vim, on n’a jamais configuré LSP
      Finalement, utiliser un IDE complet paraissait plus simple, donc il y avait toujours une hésitation vis-à-vis de l’installation et de la configuration
    • Moi aussi, j’utilise vim puis neovim depuis plus de 20 ans, mais quand LSP se casse et que les raccourcis cessent de fonctionner avec, il existe une vraie barrière psychologique à l’idée d’aller chercher la cause
      Je comprends totalement le cas de l’auteur
    • Étonnant, je n’ai pas eu de difficulté avec la configuration LSP dans og ou neovim
      J’utilise aussi une configuration minimale, assez barebones, et je n’ai pas trouvé cela compliqué ; Lua me paraît beaucoup plus ergonomique que vimscript
      C’est aussi pour cela que je continue à utiliser des outils comme ALE
      En tout cas, j’espère que l’expérience avec Helix vous rend heureux
    • Ça paraît vraiment étrange : cela fait bien plus de deux ans que le LSP est intégré à Neovim, non ?
    • On remarque que les entreprises de taille intermédiaire standardisent de plus en plus sur le tooling vscode
      On peut utiliser d’autres éditeurs, mais presque tout le débogage et la configuration sont centrés sur vscode, et l’ambiance générale pousse à son adoption
      Les configurations Neovim+treesitter+LSP sont déjà très fluides aujourd’hui ; même si c’était difficile autrefois, ce n’est plus vraiment un gros problème
      Si la motivation pour passer à Helix est le LSP, cela paraît étrange ; peut-être que le problème de l’auteur n’est pas vraiment le LSP
  • Le modèle noun-verb (objet-action) de Helix m’a semblé original au début, mais à l’usage, le modèle verb-noun (action-objet) me convient beaucoup mieux
    L’un des inconvénients du modèle noun-verb, c’est que la répétition de commande (.) devient impossible
    Dans Vim, on peut répéter des actions comme dd.., dap.., etc., mais le modèle noun-verb rend cela difficile
    Plus fondamentalement, il y a aussi un problème de manque de touches disponibles
    Trop d’opérations de base reposent sur la touche Alt, et contrairement à vim, il n’y a pas de modes normal/visual/insert distincts, seulement visual et insert
    Même la distinction entre motion et objet n’est pas claire, ce qui rend le mapping des touches plus difficile et accentue ce manque de touches
    • Le modèle verb-noun change même la manière de penser
      J’ai l’impression qu’il correspond aussi beaucoup mieux à la façon de penser nécessaire quand on écrit réellement du code
  • Le meilleur changement récent dans nvim, c’est mini.nvim
    C’est une collection de plugins créée par echasnovski, qui répond à de nombreux besoins avec cohérence et bonne documentation
    À partir de nvim 0.12 (nightly), il suffit d’installer mini.nvim et lspconfig avec le gestionnaire de plugins intégré (vim.pack)
  • Je n’en reviens toujours pas de la sensation de liberté qu’on ressent en renonçant complètement aux outils d’éditeur « avancés » comme lsp
    J’utilise neovim sans plugins, sans autocomplétion, et même sans coloration syntaxique
    J’ai le sentiment que cette autodiscipline me pousse à écrire du meilleur code
    Ce n’est sans doute pas fait pour tout le monde, mais je recommande vraiment d’essayer au moins une fois
    • On peut comprendre l’idée de vivre sans plugins ni autocomplétion, mais désactiver jusqu’à la coloration syntaxique ressemble à de la souffrance inutile
    • Je n’ai pas encore complètement basculé, mais dans Emacs, l’autocomplétion est en panne depuis un an et cela ne me manque pas vraiment
      Je n’utilise pas non plus les code actions ni goto definition, et même s’il y a parfois des erreurs en temps réel, les compilateurs sont si rapides que cela n’a pas beaucoup d’importance
      J’ai envie de désactiver LSP ; je n’ai pas l’impression qu’il ait considérablement amélioré mes capacités de programmation par rapport à il y a 20 ans
      Quant à la coloration syntaxique, je trouve au contraire que les thèmes trop colorés cassent la concentration et n’apportent rien
      Je préfère les thèmes monochromes ou à deux couleurs, et je ne ressens même pas le besoin de distinguer les noms de variables et de fonctions par la couleur
    • J’ai entendu dire que Mitchell Hashimoto travaille très bien de cette manière, et cela m’a donné la conviction qu’on peut être très productif même sans tooling moderne
      Cela dit, je me demande si le fait de devoir tout mémoriser n’accumule pas de fatigue, ou si cette méthode produit réellement du meilleur code
    • Moi aussi, je code sans aucun outil d’assistance, mais je garde toujours la coloration syntaxique activée
      Les couleurs apportent une dimension d’information supplémentaire : elles rendent les erreurs plus visibles dans le code et accélèrent la navigation
    • Dans mes projets personnels, j’ai adopté ce type de configuration minimaliste
      Sans aller jusqu’à un extrême total, je garde la coloration syntaxique ainsi que le retour sur les erreurs de syntaxe via LSP
      Je n’utilise ni autocomplétion ni liens automatiques vers la documentation
  • Si vous voulez apprendre Helix, je recommande la version remaniée de la documentation Helix réalisée par nic-revs
    helix-editor.vercel.app
    Elle est bien plus agréable à consulter que la documentation officielle, et contient beaucoup d’astuces, ce qui aide à atténuer certains défauts de Helix comme l’absence de terminal intégré, tout en apprenant des méthodes d’édition efficaces et les raccourcis
    • La lisibilité de la documentation officielle m’a toujours frustré, donc c’est une information vraiment précieuse
  • Les fonctionnalités excessivement nombreuses des distributions Neovim peuvent réellement être agaçantes
    Pour les utilisateurs de vim de longue date, je recommande kickstart, en particulier son fork modulaire kickstart-modular.nvim
    kickstart.nvim
    C’est un excellent point de départ très minimaliste
    • L’avantage de kickstart, c’est que toute la configuration tient dans un seul fichier
      En revanche, comme il est assez volumineux, je le gère plus facilement en repliant les sections avec des fold markers
 
qdr7h 2025-10-13

Je m’intéresse de temps en temps à Helix pour la simplicité du LSP et de la configuration des plugins, entre autres, mais comme mes habitudes sont trop ancrées dans vi/vim, ce n’est pas facile.