Comment utiliser l’éditeur Helix pour le développement sur serveur distant

• La raison du choix de Helix comme éditeur pour le développement sur serveur distant est qu’il peut être utilisé sans installer des dizaines de plugins comme Vim/Neovim, ce qui réduit les risques d’attaques de la chaîne d’approvisionnement
• Grâce à une configuration d’intégration avec tmux, il est possible de compenser l’absence d’explorateur de fichiers et de fonctionnalités Git TUI dans Helix, et de lancer en popup le gestionnaire de fichiers yazi, lazygit, etc.
• En important des raccourcis de style Vim, il est possible de configurer des actions comme la sélection de ligne, le déplacement du curseur ou la suppression de texte pour qu’elles se comportent comme dans Vim, et de faire en sorte que ESC réinitialise les curseurs multiples
• La barre d’état (statusline) peut être enrichie avec des informations comme la branche Git, l’encodage ou la position afin d’améliorer la productivité
• En utilisant les injections Tree-sitter, les requêtes SQL dans du code Python/Go ou les blocs de code dans du Markdown peuvent bénéficier d’une coloration syntaxique, ce qui améliore la lisibilité
• Les réglages avancés comme le LSP, la sauvegarde automatique ou les modes de couleur permettent d’augmenter la productivité et d’affiner la personnalisation

---

Pourquoi choisir Helix

• En raison de la hausse récente des attaques de la chaîne d’approvisionnement et des problèmes liés aux dépendances de plugins, Helix a été adopté à la place de Vim/Neovim comme éditeur pour le développement sur serveur distant
• Son principal avantage est d’être utilisable avec ses seules fonctionnalités natives, sans recourir à des dizaines de plugins Neovim
• Après le passage à Helix, un travail de personnalisation de la configuration a été entrepris pour reproduire autant que possible une expérience Neovim familière
• Le but est de partager cela pour faire gagner du temps à d’autres utilisateurs

Configuration de tmux

• tmux est utilisé comme multiplexeur de terminal, avec des raccourcis personnalisés ajoutés pour pallier l’absence de gestionnaire de fichiers et de Git TUI
• Helix ne permet pas d’éditer un fichier depuis l’explorateur de fichiers, ce qui était peu pratique pour naviguer rapidement entre plusieurs fichiers
• Les raccourcis suivants ont été ajoutés au fichier de configuration tmux
  • prefix - y : lance le gestionnaire de fichiers Yazi dans une fenêtre popup (95 % de l’écran)
  • prefix - g : lance Lazygit dans une fenêtre popup
  • prefix - e : ouvre l’historique de sortie de tmux dans l’éditeur Helix pour effectuer des recherches et des copies
• Le préfixe par défaut est Ctrl + b, mais il a été remplacé par Ctrl + \
• C’est utile pour le travail sur les sorties de terminal, en particulier pour copier vers Slack la sortie du client ClickHouse (CSV/JSON)
  • Cela évite des étapes en permettant de copier directement au lieu d’écrire dans un fichier
  • C’est aussi possible à la souris, mais le défilement du tampon tmux étant peu pratique, le traitement dans l’éditeur est plus efficace
• Yazi et Lazygit s’affichent généralement en surimpression au-dessus de l’éditeur Helix

Import des raccourcis Vim

• Même après s’être habitué aux raccourcis Helix, certains raccourcis Vim continuent d’être importés
• Raccourcis du mode Select
  • 0 : aller au début de la ligne
  • $ : aller à la fin de la ligne
  • ^ : aller au premier caractère non vide
  • G : aller à la fin du fichier
  • D : sélectionner jusqu’à la fin de la ligne, supprimer, puis revenir en mode normal
  • k/j : sélectionner toute la ligne au-dessus/en dessous (le comportement par défaut de Helix, avec une sélection partielle, était peu pratique)
• Raccourcis du mode Normal
  • D : supprime tout le texte à droite du curseur (ce raccourci a été repris car Helix demande trop de frappes)
  • V : passe en mode Select puis sélectionne toute la ligne
  • ESC : réinitialisation des curseurs multiples (la valeur par défaut de Helix est la virgule, ce qui est peu pratique)
• La manière dont Helix gère la sélection de lignes en mode visuel ne convenait pas, elle a donc été modifiée pour se rapprocher du style Vim
  • La configuration a été ajustée pour que le déplacement vers le haut ou le bas sélectionne la ligne entière

Barre d’état améliorée

• La barre d’état par défaut manque d’informations importantes comme la branche Git actuelle
• Configuration de la barre d’état
  • Gauche : mode, spinner, contrôle de version, nom du fichier, indicateur lecture seule, indicateur de modification
  • Centre : vide
  • Droite : diagnostics, diagnostics de l’espace de travail, position, nombre total de lignes, pourcentage de position, encodage du fichier, format de fin de ligne, type de fichier, registre, nombre de sélections
  • Séparateur : caractère │
• Cela permet de comprendre l’état de travail d’un seul coup d’œil

Raccourcis utiles

• Des raccourcis personnalisés ont fortement amélioré l’efficacité de travail, même s’ils ont pris du temps à découvrir
• Les fonctions les plus utiles : rechargement de fichier, bascule du soft wrap, Git undo, Git blame, Git diff
• Liste complète des raccourcis personnalisés
  • space - e - w : enregistrer le buffer courant dans un fichier
  • space - e - c : fermer le buffer courant
  • space - e - x : fermer tous les autres buffers (utile quand des dizaines de buffers sont ouverts)
  • space - e - l : bascule des inlay type hints (utile, mais trop bruyant si toujours affiché)
  • + - f : formater le fichier courant
  • + - w : affichage des caractères d’espacement (pour voir les caractères invisibles dans un document)
  • + - W : désactiver l’affichage des caractères d’espacement
  • space - f - . : afficher/masquer les fichiers ignorés par Git dans le sélecteur de fichiers
  • space - f - r : recharger tous les fichiers (très utile car Helix ne prend pas en charge le rechargement automatique, notamment après des modifications externes ou un commit pour mettre à jour le gutter)
  • space - f - x : annuler les modifications Git au niveau de la position courante
  • space - f - w : afficher le Git blame de la ligne courante
  • space - f - d : afficher le Git diff

Configuration de l’éditeur

• Après 6 mois d’utilisation, il a été découvert qu’une fonction de sauvegarde automatique lors du changement d’onglet de terminal existait
• Certaines fonctions récentes de Helix sont désactivées par défaut, afin d’éviter des changements inattendus pour les utilisateurs existants
• Il faut vérifier manuellement chaque option pour découvrir de nouvelles fonctionnalités
• Principales options de configuration
  • line-number = "relative" : afficher les numéros de ligne relatifs
  • rulers = [120] : définir un repère vertical visuel (utile pour limiter la longueur maximale des lignes sans formatage automatique)
  • true-color = true : forcer la prise en charge des true colors
  • completion-replace = true : l’autocomplétion remplace le mot entier
  • trim-trailing-whitespace = true : supprimer les espaces de fin de ligne
  • color-modes = true : distinguer les modes par la couleur
  • rainbow-brackets = true : utiliser des couleurs différentes pour les parenthèses imbriquées (fonction récente, pas encore disponible dans une version stable)
  • editor.file-picker.hidden = false : afficher les fichiers cachés (dot files) dans le sélecteur de fichiers
  • editor.indent-guides.render = true : ajouter des guides d’indentation visuels
  • editor.inline-diagnostics.cursor-line = "warning" : améliorer l’affichage des diagnostics (voir capture d’écran)
  • editor.auto-save.focus-lost = true : sauvegarder automatiquement à la perte de focus (nécessite la prise en charge du terminal)
  • editor.auto-save.after-delay.enable = true : sauvegarder automatiquement après un délai défini (configuré à 300 secondes)

Ajustements du LSP

• Le LSP harper-ls a été ajouté pour tous les langages afin de surligner les erreurs grammaticales dans les commentaires

Injections Tree-sitter personnalisées

• Helix permet de définir des injections Tree-sitter personnalisées, afin de colorer un autre langage à l’intérieur d’un langage donné
• Cas d’usage
  • Coloration syntaxique des requêtes SQL dans du code Python et Go
  • Mise en évidence du front matter YAML et des blocs de code dans le Markdown
  • Peut aussi servir à mettre en évidence des snippets HTML
• Les fichiers de configuration ont été publiés sur GitHub pour partager ces injections personnalisées et la configuration

• Helix est un éditeur terminal de nouvelle génération qui se distingue par ses plugins réduits au minimum, sa sécurité et sa personnalisation intuitive

[xguru]

Un développeur qui utilise Vim depuis 20 ans raconte son retour d’expérience sur son passage de Vim à Helix

[GN⁺]

Discussion Hacker News

• Je suis en train de reconstruire ma configuration d’éditeur. J’utilise Emacs depuis 20 ans et Vim depuis 15 ans en parallèle, et je n’arrive pas à choisir entre les deux. Mon objectif est de voir à quelle vitesse je peux monter une configuration assez aboutie pour être immédiatement utilisable sur du logiciel Python de niveau entreprise. Cette fois, j’essaie surtout de réduire au maximum la dépendance aux extensions tierces et de ne garder que les fonctionnalités nécessaires. Ma configuration Neovim actuelle est selon moi la meilleure que j’aie jamais eue, mais j’ai fini par utiliser plus de plugins que prévu. Du côté d’Emacs, j’en suis encore aux débuts, mais c’est intéressant de voir à quel point il a progressé au point de réduire fortement le besoin de plugins tiers à partir de la version 30. J’utilisais autrefois lsp-mode, mais aujourd’hui Eglot me convient. Le completion preview mode ne remplace pas totalement corfu, mais c’est déjà assez bon. Ma liste de plugins indispensables pour Emacs est : Magit, Expreg (treesitter expand region), Multiple cursors, dape (débogage intégré à Eglot). J’ajouterai probablement aussi Consult et orderless. Ma configuration Neovim est visible ici

  • Le nouveau nvim réduit lui aussi de plus en plus le besoin en plugins. Il fournit déjà un gestionnaire de plugins intégré, un visualiseur de diff et le lsp

  • Tu gères quand même pas mal de plugins nvim ! La semaine dernière, j’ai réécrit ma configuration nvim avec 4 plugins seulement, mini.nvim compris. J’ai eu le sentiment qu’en ajoutant beaucoup de plugins, la stabilité et la fiabilité de nvim se dégradaient nettement. Je t’envie de n’en avoir besoin que de 2 sur Emacs, et ça a l’air de fonctionner bien plus stablement comme ça. Ma configuration est visible ici

  • Après plusieurs mois d’utilisation, penses-tu toujours obtenir quelque chose de comparable à la configuration fournie de base par Pycharm+IdeaVIM ? Bien sûr, il y a le plaisir de bricoler soi-même sa config, mais si on se concentre uniquement sur l’objectif d’utiliser un IDE efficacement, passer autant de temps sur sa configuration Neovim n’est-il pas un peu inefficace ?

  • Expreg (treesitter expand region) me fait penser à combobulate (je ne l’ai pas encore essayé, mais ça a l’air chouette). Cela dit, Expreg donne l’impression d’être bien plus simple et léger

  • Les retours d’anciens utilisateurs d’Emacs m’intéressent vraiment. J’aimerais savoir comment ça se compare à Helix/Vim. Les gens qui disent que c’est bien après avoir essayé Helix/Vim pour la première fois donnent l’impression de parler sans connaître la vraie valeur d’un Emacs utilisé depuis longtemps. Il est vrai que les touches de style Vim et les modes semblent mieux intégrés dans les éditeurs modernes, mais en pratique je n’ai jamais eu assez de patience pour attendre que mes doigts s’y habituent. J’aimerais beaucoup entendre le retour d’un vrai utilisateur hardcore d’Emacs après une transition

• Pour ma part, je suis passé de Emacs à VS Code puis à Helix. Jusqu’ici, j’ai essayé d’apprendre au maximum les raccourcis existants et de l’utiliser efficacement en touchant le moins possible à la configuration. Comme il est difficile de mémoriser tout ce que Helix sait faire, j’ai fabriqué un sous-main à poser sur mon bureau avec les touches imprimées dessus. Il faudra voir à l’usage, une fois imprimé, à quel point ça aide vraiment. Mon sous-main est visible ici

  • Je serais curieux de savoir combien de temps tu as utilisé Emacs

• J’utilise principalement Emacs depuis 10 ans, et avant cela j’utilisais Sublime Text. Pour l’édition simple de fichiers ou sur un serveur distant, il m’arrive d’utiliser Vim, mais je n’ai jamais ressenti le besoin de ne travailler qu’avec Vim. J’avais construit dans Emacs mes propres modules et fonctions pour avoir un environnement parfaitement adapté. J’ai essayé Helix le mois dernier, et j’ai été surpris par la simplicité du démarrage. Les usages de base — déplacement, recherche, collage, changement de buffer/fenêtre — ont été rapides à prendre en main. Je ne connais pas bien l’histoire de Helix, mais c’est un design vraiment excellent. La recherche globale est particulièrement bonne, l’intégration lsp fonctionne exactement comme il faut, et c’est vraiment très rapide. Le fait que les valeurs par défaut soient cohérentes et utiles rend l’expérience très agréable. Je compte continuer à l’utiliser régulièrement pour m’y habituer davantage ; Emacs reste mon éditeur principal, mais Helix est si rapide qu’il pourrait devenir mon éditeur principal pour coder

• Je découvre Helix, et il y a deux inconvénients qui me sautent vraiment aux yeux

  • L’édition modale est au cœur du produit, mais avec Vim, on peut réutiliser sa mémoire musculaire telle quelle presque partout (le mode Vim est présent presque partout, il existe beaucoup d’extensions comme Vimium, et en environnement ssh il y a quasiment toujours Vim)
  • Helix vise la simplicité, donc il n’a pas d’intégration terminal et son extensibilité par plugins n’est pas très poussée (même le lint repose uniquement sur le lsp), et cette combinaison me donne l’impression qu’il faut construire une couche de setup au-dessus, ce qui me semble limitant (il faut utiliser tmux, etc.) Je ne cherche pas à critiquer ces défauts, mais je me demande quels avantages compensent cela

  • Je ne vois pas bien pourquoi le LSP serait un inconvénient. J’ai plutôt l’impression que le fait qu’il fonctionne comme processus séparé est bénéfique pour le sandboxing des plugins. En pratique, ça pourrait même mieux fonctionner que les plugins d’éditeurs traditionnels. Quant à l’absence d’intégration tmux, comme j’utilise surtout Emacs mais presque jamais de terminal intégré, ça ne m’a jamais vraiment manqué ; et si on peut simplement déplacer sa mémoire musculaire vers un éditeur rapide écrit en Rust, ça me paraît déjà suffisamment convaincant

  • On entend l’argument selon lequel les motions Vim peuvent être apprises en mémoire musculaire et réutilisées partout, mais en réalité, presque aucun développeur ne veut utiliser l’environnement Vim de base tel quel, sans plugins ni configuration. La plupart veulent un éditeur avec leur propre setup et des fonctionnalités ajustées finement. L’exception, ce sont surtout les gens qui se connectent en ssh à beaucoup de machines et ont absolument besoin de l’environnement d’éditeur par défaut. Tu évoquais la simplicité de Helix et ses limites côté plugins : au départ, Helix visait un éditeur tout-en-un, mais la communauté n’en a pas voulu, donc un système de plugins est en cours de développement. Il n’est pas encore inclus dans la release principale, mais plusieurs plugins existent déjà et sont utilisés sur une branche séparée. Je pense que retarder la sortie jusqu’à ce que le système de plugins soit suffisamment stable est le bon choix. Le plus grand avantage de Helix, c’est d’avoir amélioré l’UX inconfortable qui subsiste encore dans vi/vim/neovim. En pratique, cela permet de changer l’ordre des opérations et de voir facilement ce qui a changé avant de valider, ce qui réduit les effets de bord involontaires

• Avec une configuration de ce niveau, autant utiliser directement vim. On essaie de recréer les fonctionnalités de vim dans Helix, et Helix a lui aussi beaucoup de dépendances en interne (elles sont juste moins visibles que dans nvim). Ma configuration vim8 est restée simple depuis plus de 8 ans. J’utilise vim8 parce que c’est la version présente dans les distributions LTS. Il n’y a qu’un seul plugin chargé automatiquement (vim-tmux-navigator, pour naviguer facilement entre les splits vim et tmux), que j’ai relu moi-même et que je ne mets pas à jour. J’ai aussi deux plugins « optionnels » que j’active à la demande avec :packadd! via le gestionnaire de paquets intégré de vim. J’utilise seulement ale (lsp, diagnostics, formatage automatique à l’enregistrement) et vim-fugitive (intégration git). ale n’a aucune dépendance. vim-fugitive, une fois installé, fonctionne simplement. Si je ne charge pas automatiquement les plugins, c’est parce que vim sert généralement à de l’édition rapide ; je n’active git/lsp que sur les projets de long terme. Inutile d’utiliser des plugins dont on n’a pas besoin

  • Moi aussi, j’aime le Neovim moderne, au point d’avoir créé un package Python pour résoudre ce problème (notamment pour les gens déjà dans l’écosystème Python, ou qui utilisent uv ou pipx). On peut installer la dernière version de Neovim avec uv tool install binwheels-neovim ou pipx install binwheels-neovim, et ça fonctionne immédiatement sur Windows, macOS et Linux. Ce package encapsule les releases officielles de Neovim et utilise uv ou pipx pour récupérer le binaire adapté à l’OS et à l’architecture. Pour Linux, comme il faut prendre en charge une version de GLIBC plus ancienne que celle des releases officielles, je fournis un build séparé. Voir PyPI, le Github principal et le journal de build

  • Helix a une surface d’attaque supply chain extrêmement réduite par rapport à nvim+plugins. Tout est géré dans Helix lui-même, ce qui est bien plus sûr qu’un nvim où chaque plugin a son propre fournisseur. Les releases de Helix sont lentes et prudentes, si bien que même en cas de vulnérabilité, l’impact reste limité

  • Le modèle d’édition de Helix est supérieur

• Si on a besoin d’une TUI avec Helix, je me demande pourquoi il faudrait l’utiliser plutôt que neovim. J’aime bien les valeurs par défaut de Helix, mais dès qu’on arrive au moment où il faut changer certaines choses, ça commence à devenir de plus en plus pénible. Et si on veut une « expérience IDE complète » avec Helix, je ne vois pas non plus pourquoi on ne prendrait pas plutôt Zed, VSC ou un IDE JetBrains. Quand j’ai besoin de quelque chose de simple, j’utilise nvim ; quand il me faut plus de fonctionnalités, j’ouvre WebStorm, ou bien j’utilise ça avec un collègue quand il cherche quelque chose

  • Quand je travaille en ssh sur une machine peu puissante, Helix se lance quasiment instantanément. Obtenir le même niveau de fonctionnalités avec nvim le rend plus lent, et le coût de maintenance de la configuration et des mises à jour de plugins augmente. Et comme je connais Rust, je peux aussi contribuer à corriger des bugs. Je ne connais pas les langages de la famille C, donc je préfère les projets open source écrits dans une langue que je maîtrise. Je suis un codeur amateur qui a utilisé n/vim pendant 12 ans avant de passer à Helix ces deux dernières années. En réalité, il y a beaucoup de choses de nvim qui me manquent et qui me paraissent plus naturelles, mais Helix est vraiment prêt à l’emploi immédiatement, et ce confort compense tout le reste

  • Ces dernières années, j’ai passé un certain temps avec neovim, helix, emacs et nano, chacun à son tour, et l’expérience out-of-the-box de Helix a été de loin la meilleure. Les valeurs par défaut sont vraiment excellentes, et l’aide contextuelle ainsi que les indications sont très bien faites : on peut oublier les commandes qu’on utilise souvent, et retrouver facilement celles qu’on utilise rarement. En plus, dans ma tête, l’ordre de fonctionnement des commandes de helix paraît plus naturel que celui de vim. Les éditeurs modernes comme nvim/spacemacs ont une barrière d’entrée trop élevée à cause des plugins et de la configuration. Grâce à l’écosystème de plugins, ils peuvent faire des choses que helix ne sait pas encore faire aujourd’hui (par exemple, emacs peut servir d’IDE pour pratiquement n’importe quel langage Lisp, alors que helix ne peut pas charger de REPL), mais en contrepartie il faut apprendre non seulement l’éditeur lui-même mais aussi d’innombrables plugins, et même en cherchant la réponse, on s’y perd parce qu’elle varie selon les versions et les combinaisons. Quand on crée un nouvel environnement, on finit soit par suivre les recommandations d’autres personnes, soit par ajouter du temps d’essai et d’apprentissage. Helix est un projet récent, donc il n’a pas le poids des anciennes décisions et peut adopter des choix et des valeurs par défaut adaptés aux pratiques de développement modernes. Ce n’est pas parfait, mais si quelqu’un débute avec une TUI et veut quelque chose d’utilisable tout de suite, sans configuration, je recommanderais helix

  • hx démarre vite, s’exécute vite, et il est même joli. Les valeurs par défaut me satisfont assez, donc je n’ai fait que quelques petits ajustements ; contrairement à emacs/neovim où je vivais pris dans une boucle infinie d’amélioration, avec hx on voit la fin. La TUI fonctionne aussi très bien sur des serveurs distants, donc j’utilise le même environnement sur mac, linux et sur mes serveurs (c’est possible avec d’autres éditeurs aussi, mais hx le gère très bien). Tous les lsp dont j’ai besoin sont bien pris en charge, et la configuration languages.toml était un peu pénible, mais ce n’était pas différent des autres éditeurs

  • J’aime la simplicité de la configuration, ainsi que le selection-first editing model. Une référence à ce sujet est disponible ici. En en parlant avec des gens qui ont du mal à s’adapter à Vim, je me suis rendu compte que j’étais probablement habitué depuis le départ à un modèle « sélectionner d’abord » comme Helix. J’ai eu du mal à m’adapter aux actions de Vim où le texte cible n’est pas visible à l’avance (on ne voit la zone affectée qu’après la commande)

  • Le choix d’un éditeur est beaucoup moins une décision strictement rationnelle qu’une affaire de goût personnel, de nouveauté ou de plaisir

• Je viens seulement de découvrir la commande :reset-diff-change. Jusqu’ici, je n’utilisais que checkout -p dans git, mais le faire directement dans Helix a l’air beaucoup plus pratique

• J’ai utilisé Helix, j’ai fait l’effort de m’y adapter et maintenant je le maîtrise bien. Mais justement, j’ai fini par comprendre que ce « flux de travail inversé » est certes plus facile à apprendre et à implémenter, mais qu’en pratique il ralentit. Je suis donc finalement revenu à Vim, puis à Zed (en mode Vim)

• J’ai essayé Helix aujourd’hui pour la première fois, et c’est un éditeur vraiment très bien conçu. Cela dit, l’absence de raccourcis rapides comme y2$, dw dans Vim m’a manqué

  • En réalité, ces raccourcis n’ont pas disparu : y2$ s’écrit 2xy, et dw s’écrit wd

• Je n’ai toujours pas trouvé comment supprimer la ligne courante dans Helix en incluant aussi les lignes vides. xd supprime bien une ligne si elle n’est pas vide, mais quand la ligne est vide, deux lignes sont supprimées en même temps

  • x sélectionne la ligne courante ; si quelque chose est déjà sélectionné, il étend la sélection à la ligne suivante. X étend la sélection aux limites de ligne (sélection ligne entière). Il faut utiliser X

  • Sur une ligne vide, il suffit d’utiliser d

  • C’est discrètement agaçant. Moi aussi j’utilise un fork trivial qui change le comportement de x sur les lignes vides. Voir cette PR ici pour les détails