Vim, ou l'éditeur qui refuse de te tenir la main

Vim, c'est Vi IMproved. Le nom dit déjà tout : une amélioration de `vi`, l'éditeur qui traînait sur toutes les machines Unix depuis les années 70. Bram Moolenaar a commencé le projet en 1988 sur Amiga, sous le nom de Vi IMitation, parce que cette plateforme n'avait pas de `vi` natif. L'imitation est devenue amélioration, et l'amélioration est devenue une institution.

Tu te demandes peut-être pourquoi un éditeur de texte mérite qu'on écrive dessus en 2025. Parce que tu vas le croiser. Sur un serveur que tu administres, dans un conteneur que tu débogues, dans un `git rebase` qui tourne mal. `vi` est là. Toujours là.

Le problème que Vim résout, et celui qu'il crée

Vim est modal. Tu ne tapes pas du texte directement en arrivant. Tu es en mode normal, et les touches font autre chose : `d` supprime, `w` avance d'un mot, `dd` supprime une ligne entière. Pour écrire, tu appuies sur `i` et tu passes en mode insertion. Pour revenir, `Échap`.

Cette gymnastique a un coût. Les deux premières semaines, tu vas détester. Tu vas appuyer sur `Échap` sans arrêt, tu vas quitter l'éditeur par accident, tu vas perdre du travail. C'est le prix d'entrée, et il est réel.

Ce que tu achètes avec ça, c'est une chose précise : tes mains ne quittent plus le clavier. Pas de souris, pas de combinaisons à trois touches, pas de menus. `ci"` change le contenu entre guillemets. `dap` supprime un paragraphe. Ces commandes deviennent des réflexes, et à ce moment-là, tu écris plus vite que tu ne penses.

Le vrai coût, ce n'est pas l'apprentissage. C'est que Vim ne t'aide pas. Il ne te suggère rien, il ne t'installe rien, il ne te prévient de rien. Tu construis ton environnement toi-même, ou tu vis avec celui d'origine.

Ce que Vim est devenu, version après version

La version 1.14 sort le 2 novembre 1991, distribuée sur la disquette Fred Fish #591, un canal de diffusion physique pour la communauté Amiga. Internet n'était pas encore le tuyau qu'il est devenu.

Le 14 décembre 1993, le projet change officiellement de nom pour Vi IMproved. Une semaine plus tard, Vim 2.0 sort. En août 1994, la 3.0 apporte les buffers et les fenêtres : tu peux charger plusieurs fichiers en mémoire, en afficher plusieurs à l'écran. C'est ce qui rend Vim utilisable pour du vrai développement, pas juste pour éditer un `fstab`.

La 4.0, en mai 1996, ajoute `gvim` et une interface graphique. Tu n'es plus condamné au terminal. La même année arrivent `autocmd` et le support de la souris. Vim commence à ressembler à un éditeur moderne, sans abandonner ses racines.

Février 1998, Vim 5.0 : la coloration syntaxique arrive, et avec elle Vim script. C'est le point de bascule. La communauté peut maintenant écrire ses propres extensions, et elle ne va pas se priver. Des milliers de plugins plus tard, on y est encore.

La 6.0, en septembre 2001, apporte le folding, les plugins natifs, le split vertical et l'UTF-8. Ce dernier point compte : tu peux enfin éditer du texte en cyrillique, en arabe ou en japonais sans que tout parte en vrille.

Mai 2006, Vim 7.0 : correction orthographique, onglets, `vimgrep`. Tu cherches un motif dans tout un projet sans sortir de l'éditeur.

Septembre 2016, Vim 8.0 : I/O asynchrone, channels, jobs, timers. Tu lances un linter ou une compilation en arrière-plan sans que l'éditeur se fige. C'est tardif, mais c'est là.

La 9.1 date du 2 janvier 2024. Le projet est toujours maintenu. Trente-six ans après le début.

Terminal, GUI, ou l'un des deux selon l'heure

`vim` en terminal, c'est léger, ça passe partout, ça fonctionne en SSH sur une machine avec 256 Mo de RAM. C'est ce que tu utiliseras quand tu débogueras un service sur un serveur de production à distance, parce que c'est tout ce qu'il y a.

`gvim` te donne une vraie fenêtre, des menus, une souris qui marche comme tu attends qu'une souris marche. Le coût, c'est que tu n'es plus dans ton terminal, et que tu dois gérer deux environnements séparés.

Il existe aussi `rvim`, la version restreinte, qui bloque les commandes shell et l'écriture hors du fichier courant. Utile si tu ouvres un fichier dont tu ne contrôles pas le contenu. Et `evim`, qui démarre en mode insertion permanent, pour ceux qui veulent la puissance de Vim sans la modalité. C'est un compromis bancal, mais il existe.

Les voisins

Neovim est un fork de Vim, avec une base de code modernisée et un modèle d'extension plus propre. Si tu pars de zéro aujourd'hui, c'est probablement là que tu vas atterrir. La compatibilité avec les plugins Vim est bonne, la configuration en Lua est plus agréable que Vim script, et la communauté est active.

Helix, écrit en Rust, prend le pari inverse : modal, mais avec une sélection d'abord, comme Kakoune. Pas de mode normal au sens classique. Le tree-sitter est intégré nativement, la coloration est plus précise. Le coût, c'est que tes réflexes Vim ne fonctionnent pas, et que l'écosystème de plugins est encore maigre.

Lapce, aussi en Rust, mise sur le rendu GPU. C'est rapide, c'est joli, c'est encore jeune. Pour du travail sérieux au quotidien, tu prends un risque.

Et il y a VS Code, avec son extension Vim. Tu gardes la modalité, tu récupères les suggestions, le débogueur intégré, l'écosystème d'extensions. Le coût, c'est Electron, la consommation mémoire, et cette sensation de travailler dans un navigateur.

Ce que tu choisis vraiment

Vim ne te vend rien. Pas de télémétrie, pas de compte, pas de mise à jour forcée qui casse ta configuration. Il fait ce que tu lui dis, et rien d'autre.

C'est aussi sa limite. Tu veux de l'autocomplétion correcte ? Tu installes un LSP, tu configures `coc.nvim` ou le client natif, tu passes une soirée dessus. Tu veux du débogage intégré ? Tu ajoutes un plugin, tu écris un `launch.json`-like dans ta config. Chaque fonctionnalité que les autres éditeurs te donnent gratuitement, tu la paies en temps.

Mais ce temps, tu ne le paies qu'une fois. Ensuite, ta configuration vit dans un dépôt Git, elle te suit sur toutes tes machines, elle fonctionne en SSH sur un serveur sans interface graphique. Aucun autre éditeur ne fait ça aussi bien.

Le point qui décide, en général, c'est où tu travailles. Si tu passes tes journées dans un terminal, sur des serveurs distants, à éditer des fichiers de config et du code que tu connais, Vim ou Neovim te feront gagner du temps — après la période d'apprentissage, qui est longue. Si tu passes tes journées dans un IDE avec du refactoring, du débogage visuel et de la navigation dans un gros projet, Vim en mode terminal te ralentira, et tu le sentiras.

Reste un cas que personne n'aime évoquer : le serveur de production à deux heures du matin. Là, tu n'as pas VS Code. Tu as `vi`, ou tu as `nano`. Savoir sortir de Vim, c'est bien. Savoir y travailler, c'est mieux.