Ayant migré sous Neovim depuis quelques semaines, je vous fais un retour d’expérience et je vous donne les clés pour comprendre et réussir votre migration vers Neovim ! Avant tout un peu de contexte et d’histoire.

Vim, l’incontournable

Qui ne connaît pas Vim, ne serait-ce qu’au travers des blagues sur comment le quitter ? Et pour cause Vim - ou souvent son prédécesseur Vi, qui dépasse les 40 ans d’existence - reste souvent notre plus fidèle allié surtout sur des environnements minimaux.

Développé en 1976 par Bill Joy, Vi sera une vraie révolution, notamment en introduisant l’usage de l’ensemble de l’écran, ce qui pour l’époque est une véritable révolution. Il faut dire qu’à cette époque la majorité des éditions de texte s’effectuait à l’aide d’ed, dont Vi et Vim hériteront l’aspect modal.

Une décennie plus tard, un certain Bram Moolenaar, utilisateur de Vi, cherche à le porter sur Amiga. Il finira par développer en C la version 1.0 de Vim en 1988. Cette version se veut une version améliorée de Vi, d’où l’acronyme (VI iMproved). Celui-ci se voulant simple et efficace, il s’imposera petit à petit comme un éditeur de choix sur les systèmes Unix au côté d’Emacs.

Vim continuera d’évoluer d’années en année toujours aux mains de Bram Moolenaar, même si le rythme de cette évolution va baisser au cours des 2 dernières décennies. Ce ralentissement va être accentué par la politique de gestion des contributions, très fermée. Les propositions sont complexes à faire accepter par le créateur. De plus, il refusera régulièrement des refactoring de certaines parties, complexifiant la maintenance de Vim.

NeoVim, se réinventer sans s’oublier

Autant se l’avouer, les problématiques de développement de Vim ont fini par impacter la communauté d’utilisateurs. À tel point qu’en 2014 une partie de la communauté de Vim se lance dans le projet NeoVim, lançant notamment une collecte de fonds qui sera un succès. L’objectif de NeoVim est simple : créer un Vim plus moderne, extensible, avec de meilleures intégrations et bien sûr une communauté de développement plus efficiente.

Dès décembre 2015, la version 0.1 de NeoVim sort en offrant le support d’une très grande partie des fonctionnalités de Vim. La communauté va rapidement s’agrandir et le nombre d’utilisateurs croître. Les versions vont, elles aussi, s’enchaîner, offrant régulièrement de nouvelles fonctionnalités. Pour vous donner une idée, nous sommes aujourd’hui à la version 0.7.

Bref, un projet qui a déjà fait ses preuves et qui continue d’évoluer en gagnant de plus en plus en fonctionnalités.

Pourquoi j’utilise Vim / NeoVim en 2022 ?

À part pour des besoins de développements spécifiques, je suppose que la majorité d’entre vous utilise VSCode, même si je ne doute pas que les plus hipsters utilisent un IDE de la suite IntelliJ. Avant toute chose, oui, Vim / Neovim ne sont pas des IDEs, mais des éditeurs de code. Cela ne veut pas dire qu’ils ne peuvent pas remplir les mêmes besoins qu’un IDE une fois la configuration personnalisée et des plugins ajoutés. Bref, oui, à mon sens et pour mon utilisation, c’est comparable dans ce cas.

Je n’ai pas toujours utilisé Vim, j’ai débuté sur Eclipse dans mes premières années où j’étais développeur Java EE. Comme beaucoup, je suppose, j’avais l’impression d’utiliser un logiciel lourd, bourré de fonctionnalités surpuissantes. Mais au final d’avoir l’utilité de trop peu. Surtout qu’à cette époque, j’étais encore étudiant, autant vous dire que quand vous passez du Java au C orienté système, votre IDE n’est plus adapté.

Après mes études, je suis passé du côté obscur : je suis devenu administrateur systèmes. Autant vous dire que je passais plus de temps devant un terminal qu’autre chose, même si l’industrialisation permettait de limiter les tâches manuelles. Malheureusement, parfois on n’a pas le choix et on doit faire des modifications sans automatisation, souvent par SSH. Autant vous dire que votre IDE ne vous sera d’aucune aide. Donc j’ai fait comme tout le monde, j’utilise Vim, voir Vi. Au début, c’est compliqué : le fonctionnement modal nous paraît d’un autre temps, on se fait violence. Avec le temps, j’ai été amené à travailler en grande partie au travers d’une connexion SSH et j’ai dû commencer à me mettre à Vim et Tmux qui reste, à mon sens, un excellent combo.

Après cette période, je me suis remis à travailler sur mon poste directement. J’aurais pu repartir sur un IDE, mais au final, je commençais à m’adapter à Vim. Je n’étais pas un expert, mais ça me suffisait pour mon travail. Avec le temps, j’ai commencé à me mettre à l’aise, ajouté des plugins qui ont vraiment changé ma perception de Vim. D’un éditeur de texte très basique, où la fonctionnalité la plus avancée était la coloration syntaxique, je suis passé à un éditeur sous stéroïdes, avec un vrai moteur de compression, l’intégration de Git, et de pleins d’autres outils. En clair tout ce qu’il me fallait.

Mais voilà, à cette période Atom, puis VSCode vont gagner en popularité, en particulier dans le milieu DevOps. Je ne vais pas vous mentir : devant tant de personnes conquises, j’ai testé. C’est à ce moment que j’ai compris deux choses : Vim, avec ma configuration et mes plugins, était tout aussi puissant en termes de fonctionnalités pour mon usage et surtout, Vim avait changé ma manière de travailler. Quand je dis “changé ma manière de travailler”, c’est, en particulier, pour un détail qui va vous sembler con : Vim est dans un terminal. Couplé à Tmux c’est devenu, pour moi, un combo idéal. L’organisation de mes espaces de travail Gnome, de mes écrans, en fait tout mon workflow de travail a fini par s’axer là-dessus. J’ai donc décidé de retourner sur Vim, tout en continuant de faire évoluer ma configuration.

Ce qui change au quotidien

Quand j’ai vu passer Neovim, il me semble qu’il était en 0.2. À l’époque, je me suis dit : “ah encore un fork qui n’apporte pas grand-chose”. Du coup, je suis resté sur Vim. Surtout que la version 8, sortie récemment à l’époque, apportait des fonctionnalités sympas, notamment le support de l’asynchrone. J’ai quand même suivi de loin l’évolution de NeoVim.

Un jour, est sortie une nouvelle version 0.5 de NeoVim, et celle-ci a été, je pense, un vrai argument pour commencer à considérer la migration. Cette mise à jour apportait beaucoup de fonctionnalités très intéressantes. Bien sûr un client pour le LSP (on en parle juste après) totalement intégré, un meilleur support de la configuration Lua, un nouveau système de parsing pour la coloration syntaxique notamment (Tree-sitter).

Au final j’ai fini par céder et tester devant la liste des apports de celui-ci :

• Avoir un client pour LSP directement intégré
• Pouvoir faire une configuration en Lua : Vimscript a rapidement ses limites
• Plus ouvert : beaucoup de plugins intéressants commencent à n’être disponibles que sur NeoVim
• La documentation est complète
• Mine de rien, une communauté plus dynamique, avec souvent une approche moderne

Je vous passe les corrections de bugs et petites joies de tous les jours, notamment sur les paramètres par défaut, qui sont bien moins austères que Vi ou même Vim. Pour beaucoup, cette liste doit-être floue et c’est bien normal ! Au-delà de la liste, je vous propose de faire un petit tour de ces nouveautés, ce qu’elles apportent et surtout comment elles fonctionnent.

Lua

Si vous êtes un utilisateur de Vim un minimum avancé vous avez déjà été confronté au fameux VimScript, le langage qui permet de configurer votre installation, mais aussi de faire des plugins. On ne va pas se mentir, c’était un point désagréable pour beaucoup de monde, moi compris. Avec Lua on a gagné en confort et en possibilités.

J’ai eu un peu peur d’avoir du mal au départ n’ayant jamais utilisé de Lua, mais c’est assez clair et simple. Pour être plus à l’aise, j’ai quand même pris quelques minutes pour connaître les bases et pour cela je vous conseille ce site.

Une chose est tout de même à remarquer : vous pouvez avoir pas mal de soucis si, comme moi, vous découpez trop votre code. En soit on peut le corriger, mais personnellement ça m’a pas mal fatigué pour un apport minime donc j’ai mis tout mon code dans un fichier. Cela reste lisible, d’ailleurs ma configuration Neovim est toujours sur Github.

Petit exemple de code en Lua :

function map(mode, shortcut, command)
  vim.api.nvim_set_keymap(mode, shortcut, command, { noremap = true, silent = true })
end
map('', '<C-D>', ':Telescope find_files<CR>')
map('', '<C-F>', ':Telescope grep_string<CR>')
map('', '<C-X>', ':NvimTreeToggle<CR>')

Après si vous êtes un fan de VimScript, déjà pourquoi ? Et sinon, NeoVim le supporte aussi.

Packer

Je parle de plugins depuis le début de l’article, mais utiliser un éditeur simple n’implique pas de tout faire à la main. J’utilise donc depuis longtemps un gestionnaire de plugins et si vous ne le faites pas, je vous conseille vivement de vous y mettre : c’est très pratique. J’utilisais Vim plug qui était tout ce que j’aime : simple et efficace.

Mais avec NeoVim, tout un nouveau monde de plugins s’offre à nous. Et parmi ces plugins, l’un d’eux, très populaire, permet de gérer les plugins : il se nomme Packer et n’est pas développé par Hashicorp.

Celui-ci propose, à mon sens, tout ce que je pouvais attendre d’un gestionnaire de plugins sous Neovim :

• Développé et configuré en Lua
• Gère les dépendances
• Beaucoup d’options d’installation et de gestion
• Gère les installations au travers de tâches asynchrones
• Supporte Git notamment au niveau des tags

Le manager fonctionne bien, permet d’installer, mettre à jour et supprimer différents plugins. Au-delà de ça, il s’installe facilement, de manière automatique, avec quelques lignes de code Lua :

local fn = vim.fn
-- Automatically install packer
local install_path = fn.stdpath "data" .. "/site/pack/packer/start/packer.nvim"
if fn.empty(fn.glob(install_path)) > 0 then
  PACKER_BOOTSTRAP = fn.system {
    "git",
    "clone",
    "--depth",
    "1",
    "https://github.com/wbthomason/packer.nvim",
    install_path,
  }
  print "Installing packer close and reopen Neovim..."
  vim.cmd [[packadd packer.nvim]]
end

L’installation de plugins est tout aussi simple et efficace :

require('packer').startup(function(use)
  use 'wbthomason/packer.nvim' -- Package manager
	# Mettez tous vos plugins
  use { 'nvim-telescope/telescope.nvim', tag="nvim-0.6", requires = { 'nvim-lua/plenary.nvim' } } #Plugin avec une dépendance et un tag
end)

Pour interagir avec Packer, rien de plus simple : il vous suffit d’utiliser la console NeoVim pour exécuter les commandes, comme par exemple PackerInstall, PackerSync.

À noter: Neovim ayant un cycle de développement plus régulier, les plugins, eux aussi, sont souvent mis à jour. Si vous n’êtes pas sous la dernière version de Neovim, n’hésitez pas à tag les installations des plugins. J’ai eu quelques surprises malheureuses : des plugins, qui, une fois mis à jour, n’étaient plus compatibles avec les anciennes versions de NeoVim. Cela se fait simplement comme dans l’exemple donné plus haut.

LSP

Il faut l’avouer, une des faiblesses de Vim, pendant longtemps, était la qualité de la compression, plus spécialement du moteur qui permettait à l’éditeur de comprendre la structure du code afin de faire de l’autocomplétion ou encore de remarquer des problèmes syntaxiques et j’en passe.

Cette situation a déjà changé, il y a quelques années, grâce notamment à Micosoft. Il y a quelques années, il décide de créer un protocole de communication entre un IDE (historiquement VSCode) et des serveurs permettant de renseigner celui-ci sur la structure et les fonctionnalités du langage. Dès 2016, ils vont travailler avec RedHat pour standardiser ce protocole qui va devenir : Language Server Protocol. Une fois le protocole publié, de nombreuses implémentations ont vu le jour, celui-ci se basant sur Json-RPC, il est possible de l’intégrer à une très grande liste d’éditeurs.

Vim, d’ailleurs, pourra utiliser LSP assez rapidement. J’ai, d’ailleurs, commencé à l’utiliser il y a 2 ans, avec le plugin Conquer of Completion, qui apportait un support total de LSP. Une fois le client installé sur votre éditeur, il n’y a plus qu’à installer la partie serveur, ce qui se fait facilement, en recherchant les serveurs disponibles sur le site de LSP.

Même s’il est possible de l’utiliser en Vim, Neovim va apporter un client natif parfaitement fonctionnel, qui simplifiera l’installation, et nous permettra de profiter de fonctionnalités dignes des éditeurs les plus en vogue.

Il est à noter que, même si Neovim intègre le client, certains plugins sont nécessaires à LSP pour vous offrir une meilleure expérience de l’intégration. Je vous conseille :

• nvim-lsp-installer qui vous permet d’installer les serveurs de langage directement à partir de la console Neovim
• nvim-lspconfig qui, lui, regroupe un ensemble de configurations de base pour LSP
• cmp-nvim-lua qui va permettre d’afficher les petites fenêtres pour l’autocomplétion.

Si vous souhaitez vérifier que votre éditeur a bien détecté le langage et utilise le bon serveur, vous pouvez utiliser la commande :LspInfo, qui vous affichera toutes les informations du client LSP.

Il peut arriver que votre éditeur n’associe pas un type de fichier au serveur de langage. Dans ce cas, vous pouvez lui préciser, comme ci-dessous :

require'lspconfig'.terraformls.setup{
	capabilities = capabilities,
	filetypes = { "tf", "tfvar", "terraform" }
}

Astuce bonus, vous pouvez lancer un diagnostic de votre Neovim, afin d’identifier certains problèmes. Pour ça, rien de plus simple : un outil embarqué existe. Exécutez juste :checkhealth.

Telescope, fzf boosté

Très souvent quand vous commencez à personnaliser votre Vim ou Neovim, vous installez un plugin vous permettant d’afficher l’arborescence dans votre éditeur. C’est sympa, ça permet d’avoir une vue sur la structure, mais pour se déplacer d’un fichier à l’autre c’est lent. Donc, très rapidement, on se tourne vers Fuzzy-finder. Et là, généralement, on revit et on a plus envie de quitter son éditeur.

Fzf c’est bien, mais comme je le disais au-dessus, Neovim offre beaucoup de nouveaux plugins avec de nouvelles implémentations. Et parmi elles, un fzf survitaminé : Telescope ! Il vous permet de rechercher des fichiers, et même des patterns de texte, tout en offrant une interface avec de la prévisualisation de fichiers ! Un must have, tout simplement.

Enfin la version de Vim qu’on attendait ?

Quand je me suis décidé à migrer sous Neovim, j’ai préféré faire table rase des Vimscripts, au profit de Lua. Et avec le recul, je pense que c’était la bonne approche. Néanmoins, je dois reconnaître que j’ai perdu pas mal de temps, notamment à vouloir, à tout prix, trop diviser mes fichiers de configuration, ce que Lua visiblement n’aime pas. J’ai fini par utiliser une base simple trouvée sur le Net et l’adapter à mon goût. J’ai tout de même conservé le thème qui est un bel hommage à Atom.io que j’avais essayé.

Vim était clairement mon IDE / éditeur de code principal, j’ai longtemps hésité à changer, n’étant pas sûr de l’apport. Au final, la transition se fait bien : Neovim est une belle évolution, mais il ne détruit pas l’héritage de Vim. Nous retrouvons donc le système modal, la légèreté, le fonctionnement en terminal natif et tout ce qui fait le charme de Vim. Après, si vous avez détesté votre expérience sous Vim, je doute que vous tombiez sous le charme de Neovim.

Au-delà de ces considérations, je trouve ça toujours aussi incroyable, qu’un éditeur si ancien ait toujours sa place, et une communauté aussi active. Il est, d’ailleurs, possible de soutenir le développement de Neovim, en aidant les développeurs sur Github ou en les finançant sur OpenCollective.

Pour ce qui est de ma configuration, elle est disponible sur le dépôt Github suivant : ansible-personal-computer comme toutes mes configurations.

Head photo by Vadim Sherbakov on Unsplash