Lettre d’amour à Neovim

• Neovim fait aborder l’édition de code non pas comme de la frappe rapide, mais comme une boucle répétée de déplacement, modification, suppression, réorganisation et vérification des tests
• La grammaire d’édition de Vim réduit la friction de l’édition répétitive en combinant des opérations par unité de sens comme ci", dap, ., les macros et les objets de texte
• Neovim n’impose ni explorateur, ni terminal, ni panneau Git, et laisse l’utilisateur choisir autour des buffers des outils comme Telescope, Fugitive ou le LSP
• La configuration peut être possédée sous forme de fichiers versionnés dans Git et reste une partie du système qui fonctionne avec le shell, tmux, ripgrep, git et les language servers
• Il a été modernisé avec Lua, le LSP intégré, Treesitter et Lazy.nvim, mais sa valeur centrale est que les gestes appris s’accumulent dans le temps et font évoluer directement le workflow

---

Du ressenti de travail, de Vim à Neovim

• L’usage de Vim a commencé en 2011, et au début il ne comprenait ni pourquoi il copiait un .vimrc, ni pourquoi j déplaçait le curseur au lieu d’insérer un caractère
• La première semaine a été difficile et le premier mois déroutant, mais une fois le modèle de Vim assimilé, les autres éditeurs ont commencé à donner l’impression d’avoir une couche tampon entre le code et l’utilisateur
• Il a essayé de nombreux éditeurs, dont VS Code, les IDE JetBrains, Sublime, Atom et Zed ; les outils JetBrains sont extrêmement puissants, et VS Code a réussi parce qu’il est suffisamment bon pour presque tout le monde et facile à étendre
• Malgré cela, il continue d’utiliser Neovim parce qu’il s’aligne sur sa manière de travailler et soutient directement la boucle répétitive de l’édition de code

Traiter l’édition non comme des raccourcis, mais comme un langage

• Éditer du code ne consiste pas à taper vite, mais ressemble davantage à une répétition de déplacements, petites modifications, suppression de mauvaises abstractions, réorganisation de fonctions, déplacement de fichiers, puis vérification des tests et des diagnostics
• La plupart des éditeurs traitent le texte comme un document et le clavier comme un périphérique de saisie, alors que Vim traite l’édition comme une grammaire
• ci" remplace le contenu entre guillemets, dap supprime un paragraphe, et . répète la dernière modification
• Les macros permettent d’enseigner une petite routine une seule fois pour la répéter sur tout un fichier, et les objets de texte permettent d’appliquer des opérations à des unités de sens plutôt qu’à un simple nombre de caractères
• Une fois la grammaire de Vim entrée dans les mains, on passe moins de temps à faire glisser le code à la souris, cliquer dans une barre latérale ou ouvrir la palette de commandes pour des tâches répétées des dizaines de fois chaque jour
• Les opérations fréquentes deviennent de petits mouvements directs, et le bruit de l’éditeur diminue

Neovim n’impose pas votre workflow

• Les éditeurs centrés sur l’interface graphique ont souvent une vision figée de la place et de la forme de l’explorateur, du terminal, du panneau Git et du débogueur, et avec le temps l’éditeur finit par ressembler à un cockpit
• Neovim commence avec les buffers, et c’est à l’utilisateur de décider ce qu’il place autour
• Si l’on a besoin d’un arbre de fichiers, on peut l’ajouter ; pour la recherche floue, on peut choisir l’outil qui convient, comme Telescope ou fzf-lua
• Pour l’intégration Git, on peut utiliser Fugitive, et le LSP, les diagnostics, le formatage, les snippets, Treesitter, les lanceurs de tests et l’autocomplétion peuvent être gérés sans que l’ensemble se transforme en un lent tableau de bord Electron
• La vitesse n’est pas seulement une question de temps de démarrage, c’est aussi une question de confiance
  • quand on appuie sur une touche, la réponse doit être immédiate
  • l’ouverture de gros fichiers ne doit pas faire hoqueter toute l’interface
  • en SSH, en pairing sous tmux ou dans une petite fenêtre de terminal, l’éditeur doit conserver au quotidien la même sensation d’usage
• Qu’il s’agisse d’un projet local, d’un serveur distant, d’un changement rapide de configuration, d’une grosse application Rails, d’un petit script shell ou de la rédaction en Markdown, on peut réutiliser les mêmes déplacements, les mêmes commandes et la même mémoire musculaire
• Cette cohérence s’accumule sur toute une carrière

Une configuration maîtrisable et un outil qui reste une partie du système

• La configuration de Neovim est faite de fichiers dans Git : on peut donc les lire, les casser, et en supprimer la moitié quand on réalise qu’un plugin ne sert à rien
• On ne dépend ni d’une mystérieuse base de données de configuration, ni d’un état de synchronisation de compte à moitié compris, ni d’extensions qui se comportent bizarrement en arrière-plan à cause d’une case à cocher modifiée plusieurs versions plus tôt
• Beaucoup d’éditeurs modernes veulent devenir l’endroit où tout se passe, mais Neovim se satisfait d’être une partie affûtée d’un système plus large
• Il n’essaie pas de remplacer le shell et fonctionne avec tmux, ripgrep, git, les language servers, les formatters, les linters et les test runners
• Le fait de ne pas avoir besoin de posséder tout le bureau fait aussi partie des raisons pour lesquelles Neovim a duré
• Depuis 2011, de nombreux éditeurs, écosystèmes d’extensions, thèmes, marketplaces et panneaux IA sont apparus ; pourtant Vim était déjà un ancien outil, et Neovim a modernisé ce qui devait l’être sans abandonner ce qui comptait pour les gens

Modernisation et récompense durable de l’apprentissage

• Lua a rendu la configuration meilleure, et l’écosystème des plugins s’est lui aussi nettement amélioré
• Le LSP intégré apporte à l’éditeur des fonctions d’IDE sans donner une impression de lourdeur
• Treesitter a modernisé la coloration syntaxique et la compréhension du code, et Lazy.nvim a rendu la gestion des plugins rapide et simple
• Le principal attrait de Neovim est que ce qu’on apprend continue d’être utile avec le temps
  • apprendre un mouvement continue d’aider durablement
  • écrire une macro fait disparaître les éditions ennuyeuses
  • découvrir les objets de texte rend les refactorings pénibles plus faciles
  • ajuster une commande finit par en faire une extension de la main
• Un éditeur ne devient pas meilleur parce qu’une entreprise lance une nouvelle barre latérale, mais parce que l’utilisateur devient plus habile à s’en servir
• La productivité se mesure difficilement à un simple « 5 secondes gagnées ici » ; elle réside dans la réduction de friction sur des milliers de petites éditions
• On peut naviguer entre le code, les tests, les git diff et les résultats de recherche tout en restant concentré sur le problème, sans avoir l’impression de passer d’une pièce à une autre
• Neovim, par sa grande programmabilité, pousse à façonner soi-même son workflow plutôt qu’à accepter les valeurs par défaut
• Si une gêne se répète deux fois, on peut généralement la corriger avec un mapping, une commande, une petite fonction Lua, un meilleur plugin, ou en supprimant un plugin
• La configuration évolue en fonction de la manière réelle de travailler, et quand le changement souhaité est clair, il reste très peu de choses entre la pensée et l’édition
• En 15 ans, les langages, les frameworks, la puissance des machines et les modes du secteur ont changé, mais Vim et Neovim sont restés l’éditeur central où s’effectue le meilleur travail

[GN⁺]

Avis sur Lobste.rs

• J’ai commencé à utiliser vim il y a 12 à 14 ans parce qu’il me fallait un éditeur léger qui affiche le code juste devant moi
  J’ai commencé à apprendre à m’en servir sans la souris, et plus tard j’ai été content d’apprendre que Mitchell Hashimoto avait découvert vim d’une manière similaire
  J’ai découvert neovim via TJ DeVries(https://www.youtube.com/@teej_dv) et sa chaîne YouTube, où je l’ai vu bricoler sur divers projets comme neovim, telescope, etc.
  Le passage à Lua m’a semblé naturel, et comme c’était déjà un petit langage que j’aimais bien, ça m’a plu
  Les premiers plugins que j’ai utilisés étaient treesitter et telescope, et j’utilise encore neovim aujourd’hui avec quelques petits plugins
  neovim ne m’a jamais lâché, ça fonctionne simplement bien. Je n’utilise pas de plugin LLM, et à mon avis cet écosystème peut très bien rester hors de l’éditeur
  J’espère que l’équipe continuera à ne fournir qu’un éditeur de code léger et focalisé

  • Expérience similaire. J’ai utilisé vim et emacs pendant des années, avec une préférence pour vim, mais j’ai toujours envié le fait que elisp soit un langage de programmation plutôt correct alors que vimscript laissait un peu à désirer
    C’est pourquoi l’ajout de Lua dans neovim m’a paru très séduisant

• Il y a environ 20 ans, j’ai réfléchi à ce qui, au-delà de la simple productivité, rendait le quotidien agréable
  Tout en haut de la liste, il y avait linux et vim
  Quel que soit le travail à faire ou la stack technique utilisée, ces deux outils me garantissaient un environnement de travail ergonomique, familier et confortable

• C’est vers 2009, pendant des entretiens d’embauche, que j’ai commencé à apprendre vim au-delà de :wq, simplement parce que tous les employés l’utilisaient et qu’il n’y avait pas d’autre moyen de collaborer avec eux
  Certains allaient même jusqu’à désactiver les touches fléchées
  Avant ça, mon expérience des éditeurs en terminal se limitait surtout à pico à l’université, et j’utilisais au quotidien les éditeurs GUI populaires de l’époque
  Heureusement, j’ai été embauché, et depuis j’utilise vim en continu
  Récemment, j’ai réalisé que la manière de penser propre à vim s’était infiltrée dans d’autres aspects de ma vie logicielle
  Je pense que ça a commencé quand j’ai créé dans Hammerspoon sur macOS un clavier virtuel pour des sous-mappages de gestion de fenêtres, et l’an dernier, en essayant Arch Linux, la gestion de fenêtres en tuiles est devenue vraiment simple
  Je suis passé à neovim il y a quelque temps déjà et je le trouve vraiment excellent
  Je sais qu’il existe beaucoup de blagues et de débats sur les éditeurs, mais à quelques exceptions près, j’ai encore du mal à comprendre que des gens qui écrivent du code professionnellement n’utilisent pas vim, emacs ou un éditeur similaire
  Dans n’importe quel métier, il est important de choisir les meilleurs outils pour le travail, et traiter l’édition comme un langage est un gros avantage en software

  • Le point central du billet, c’est « pourquoi j’aime Neovim », pas « pourquoi il faudrait l’utiliser »
    Quant au passage sur le fait que ce soit « difficile à comprendre », le fonctionnement, les raccourcis et les plugins d’éditeurs comme VS Code sont eux aussi très utiles
    Ça vaut le coup de lire sérieusement la documentation de VS Code, il fait réellement beaucoup de choses
    Et pour certains, moi y compris, déplacer le curseur à un endroit arbitraire d’un buffer avec la souris et sélectionner une plage arbitraire est simple et suffisamment rapide
    KISS
  • J’utilise les modes vi et les commandes de déplacement presque partout, mais je n’utilise vi, vim, neovim ou viper d’emacs qu’occasionnellement
    C’est souvent parce que d’autres éditeurs sont de meilleurs outils pour le travail concerné
    En Python, que j’utilise le plus souvent en ce moment, j’ai l’impression que PyCharm est un meilleur outil qu’eux
    Heureusement, il existe un excellent plugin appelé IDEAVim, ce qui permet de conserver la mémoire musculaire
    Sur mac aussi, c’est un avantage que les raccourcis système n’entrent pas en conflit avec les raccourcis vi, ce qui permet de choisir selon le contexte
    Quand je fais du C++, je considère que CLion est un meilleur outil, et IDEAVim y fonctionne aussi
    Pour les tâches diverses à la frontière des catégories, j’utilise souvent zed, dont l’émulation vim est également assez bonne
    C’est évidemment agréable d’avoir un bon éditeur terminal quand on se connecte à un système distant, mais quand on peut utiliser une interface GUI complète, je n’aime pas particulièrement les éditeurs terminal
    J’aime bien l’édition modale, mais s’il n’est pas nécessaire d’abandonner sa mémoire musculaire, il y a aussi de très bonnes raisons d’utiliser un éditeur GUI

• VS Code, dans son état de base, est déjà suffisamment bon pour beaucoup d’usages
  Il propose déjà la recherche de fichiers en ctrl-p, les vues fractionnées, la coloration syntaxique et la prise en charge des langages populaires
  J’espérais que neovim fournirait au moins quelque chose comme ctrl-p par défaut, et qu’il deviendrait une sorte de Linux Mint des éditeurs à la vim, avec moins de soucis de sécurité et une barrière d’entrée à la configuration plus basse
  Je comprends l’idée de vouloir retrouver la même sensation d’éditeur que celle qu’on utilise tous les jours quand on fait du pair programming dans une session tmux sur une machine accessible en SSH, ou quand on corrige un problème dans une petite fenêtre de terminal
  J’ai gagné de l’argent pendant longtemps à écrire beaucoup de code via screen/vim au-dessus de SSH, et c’était réellement très productif à l’époque, avant les interruptions permanentes du type Slack qui peut sonner à tout moment
  Les débogueurs visuels de Visual Studio ou des IDE Jetbrains comme CLion et Rider sont une chose pour laquelle je n’ai jamais trouvé de bon équivalent dans un éditeur vim
  Il y a là une puissance plus accessible que dans des outils comme cgdb
  La vitesse ne se résume pas au temps de démarrage, et neovim est bon sur ce point aussi, mais la fermeture de neovim par défaut est nettement plus lente que celle de vim
  Même si ce n’est pas très long, dans mon environnement cela prend environ 1 seconde

• J’aime le modèle de vim. L’édition modale n’en est qu’une petite partie, et ce que j’apprécie davantage dans vim que dans helix ou un IDE classique, c’est la possibilité d’apprendre progressivement
  On commence par comprendre les raccourcis clavier et les options, puis quand quelque chose ne marche pas sous Windows on ajoute une condition dans la config, puis on écrit des autocmd et des fonctions, et avec tout ce qu’on a appris on finit même par étendre ça à de petits plugins
  Cela dit, je n’aime pas profondément vim ou neovim
  vim traîne depuis des décennies les mêmes bugs bizarres jamais corrigés, et neovim en a réparé beaucoup tout en en introduisant d’autres
  Le plus grand tort de neovim, c’est de casser l’API Lua à chaque mise à jour
  Je suis fatigué de voir des avertissements d’obsolescence à chaque lancement et de devoir corriger ma configuration avant même de pouvoir faire ce que j’avais prévu
  Ce serait déjà moins pénible si certaines nouvelles fonctionnalités n’étaient pas réservées à Lua
  Sinon, j’aurais pu continuer à n’utiliser que vimscript et me satisfaire d’une compatibilité maintenue depuis plus de 20 ans