2024 vim est encore populaire
Si vous êtes entré dans vim pour la première fois et sans doute par erreur,
:qa!
quitte vim et sans sauvegarder.
J’utilise neovim tous les jours. Que ce soit pour de la programmation, de la configuration, ou rédiger un blog, neovim est mon éditeur de texte principal. La plupart de mes collègues qui me voient se disent ‘mais pourquoi ?’. Il y a vscode qui est l’éditeur de texte le plus populaire et qui marche extraordinairement bien. L’enquête de stackoverflow 2023 le prouve. Ses plugins permettent d’ajouter des tas de fonctionnalités, il est stable, démarre rapidement.
Cet article n’est pas pour vous convaincre d’utiliser vim. C’est un article pour vous expliquer pourquoi je l’utilise, et pourquoi il est encore populaire. Qu’est-ce qu’il m’apporte et pourquoi je ne planifie de le garder.
Une section sera dédiée pour ceux qui désirent tester neovim, expliquer les différents modes de consommations, et quelques conseils. Sans volonté d’être complet, cette section parle de point de départ pour utiliser neovim, sujet très peu évoqué dans d’autres médias. Mais quelque soit votre choix, le reste est correctement documenté sur le net.
Cet article cible les lecteurs qui ne connaissent pas neovim. Si vous connaissez déjà, seul la première partie qui partage mon expérience personnelle peut vous intéresser. Sinon, la seconde partie est destinée à ceux qui sont curieux de le découvrir.
De visual studio, a visual studio code, a neovim⌗
J’ai commencé mon parcours professionnel avec Visual Studio. Rien à dire de spécial, il est encore aujourd’hui l’outil principal la majorité des développeurs que je côtoie. Un outil classique pour la majorité des développeurs. Nouveau dans l’industrie, c’était judicieux de rester sur un IDE connu pour continuer mon apprentissage plus important à l’époque.
Les années passent, et en 2018, je me suis retrouvé face à un constat et un problème :
- Je suis dépendant de mon IDE. À cette époque, je savais compiler et déployer uniquement depuis visual studio. L’absence d’IDE signifiait pour moi une incapacité à compiler.
- Naviguer dans plusieurs bases de code n’était pas possible à cause de la mémoire RAM de l’ordinateur fourni.
Visual Studio remplace les outils de builds. Il ne les complète pas.⌗
Le constat vaut la peine de développer un peu plus. À une époque, nous construisons un projet avec des versions spécifiques de visual studio. Vous vous souvenez sûrement de l’époque où la compilation devait se faire sur une version spécifique. Si ça ne compile pas en VS2013, utilisons VS2012 car ça a tout le temps fonctionné. Encore aujourd’hui, je ne saurais pas expliquer quel était la cause. Mais je peux dire que ça n’est pas une situation souhaitable.
Nos projets sont dépendants des outils de Microsoft. Je ne souhaite à aucune entreprise d’être directement dépendant d’une autre. Être vendor lock est une situation qui m’inquiète énormément. Le business dépend de la bonne volonté du fournisseur de continuer à fournir l’outil, sans le casser, et au prix qu’il désire. Par chance, Microsoft n’a pas abusé de cette position de force (ou informez-moi si vous avez des contre-exemples). Mais des exemples plus délicats s’est déjà présenté dans d’autres industries.
Aujourd’hui encore, je vois quelques projets legacy qui ont besoins de dépendances de VS pour compiler. Ils se font heureusement de plus en plus rare, et que ces projets sont des exceptions plutôt que la norme me rassure.
Machine sous-sizé⌗
Fréquemment, les clients me fournissent un ordinateur qui n’a pas de configuration satisfaisante pour développer. Un CPU et de la mémoire juste ce qu’il faut pour faire tourner un navigateur, word et excel. Et malgré la machine sous-estimée pour nos tâches, il me fallait pouvoir ouvrir 5 projets différents pour comprendre de bout en bout le flux de données et de process entre les services. Avoir 5x visual studio (et souvent avec resharper) était excessivement gourmand.
Il me fallait une alternative à Visual Studio pour être efficace dans ces conditions.
Visual Studio Code comme solution de l’époque⌗
Ces 2 constats m’ont poussé à sélectionner vscode. Mon habitude de travail de cette époque était d’utiliser vscode pour ouvrir beaucoup de projet et les parcourir, et de me forcer d’utiliser les outils de terminal pour les apprendre.
Par chance, cette migration est arrivée en même temps que la sortie du dotnet cli
. Ainsi, j’étais capable de construire les applications sans besoins d’un IDE ou d’outil payant particulier. J’étais satisfait. En plus de ne plus dépendre d’un IDE, le terminal intégré m’invitait a utiliser des commandes non-spécifiques à un IDE.
Les IDEs sont des aides, pas un prérequis.
Douleurs et ordinateur sous-spécifié à l’extrême⌗
En 2021, une douleur au poignet gauche démarre. Je ressentais une douleur plus forte après une longue journée à écrire au clavier. Afin de limiter la douleur, 2 choix 2 changements se sont imposés. Changer de clavier pour un ergonomique (un Dactyl Manuform. On en parlera peut-être dans un autre sujet), et adapter mes outils à moi. Jusque-là, je sélectionnais les outils, j’apprenais leurs conventions et raccourcis clavier, et après m’être adapté, je pouvais être productif.
Cette douleur m’a poussé à changer cette façon de consommer les outils. Et c’est avec cette volonté que Neovim est devenu une solution viable pour moi. Neovim étant configurable à l’extrême, je pouvais toujours trouver une configuration satisfaisante.
De plus, c’est aussi cette année que je travaillais avec un ordinateur extrêmement sous-spécifié. De mémoire, il y avait 4 Go pour windows 10, et nous travaillions sur 7 solutions .net en même temps. Nous devions choisir entre
- Ouvrir 1 visual studio
- Ouvrir 2 visual studio code
- Ouvrir 1 visual studio code, et faire tourner tous les autres services en CLI.
Débugger 3 applications en même temps était impossible. Neovim m’a permis d’ouvrir plusieurs de ces projets avec un impact sur la mémoire acceptable.
Cet ordinateur n’a pas été l’argument principal pour changer d’IDE, mais couplé avec la douleur au poignet, ça a été un élément motivateur pour migrer.
Aujourd’hui, mon laptop fournis par mon client dépasse ces restrictions. Un manque de mémoire n’est pas un argument suffisant pour rester sur neovim. La suite du post vous explique ces bénéfices que j’aime aujourd’hui. La restriction de mémoire était une raison pour démarrer neovim, mais maintenant, c’est son efficacité qui me garde sur cet éditeur de texte.
Pourquoi utiliser ‘un vieux truc’ ?⌗
Le contexte est maintenant posé, cassons quelques idées reçus.
Je me souviens de la première fois avoir demandé dans un chat communautaire si quelqu’un avait une expérience avec (neo)vim pour avoir un premier retour. Les mêmes que j’avais avant de découvrir ce qu’était vim.
Pourquoi utiliser un outil du passé ? Il ne fonctionne que dans le terminal, c’est vieillot
Un an avant ma migration, j’étais naïvement d’accord avec eux. Toutefois, prenant le temps de vérifier ces 2 arguments.
Neovim est moderne⌗
Neovim tourne nativement sur windows.
Neovim est un fork de Vim. Vim était essentiellement basé sur un développement d’un dictateur bienveillant, Bram Moolenaar. La communauté était désireuse de fournir une alternative. Vim et neovim partagent des tonnes de qualités et fonctionnalités communes. Entre autre, et les 2 différences les plus flagrantes sont :
- La configuration en lua et utilisé dans d’autres domaines au lieu du vimscript propre a vim.
- Un client lsp intégré.
Lua est un langage simple, dynamique et typé faible. Il permet de facilement apprendre le langage, au prix d’avoir de temps en temps des bugs causés par une faute de frappe.
-- ce code est valide
local my_object = {}
my_object.foo = 'bar' -- dynamic
local is_equal = 0 == '' -- faible
Il convient très bien pour l’usage requis avec neovim : le configurer et y ajouter des fonctionnalités.
-- inséré un ';' a la fin de la ligne sans changer la position du pointer.
function execute_then_come_back_at_original_position (fn)
local row, column = table.unpack(vim.api.nvim_win_get_cursor(0))
fn()
vim.api.nvim_win_set_cursor(0, { row, column })
end
vim.keymap.set("n", "<leader>e;", function()
execute_then_come_back_at_original_position(function()
vim.cmd ":normal A;"
end)
end, {})
Avec le lua, je peux ajouter des fonctionnalités à mon éditeur de texte, et configurer des proxys envoy.
Aussi, neovim intègre un client LSP. Pour rester simple, ça n’est pas le sujet, le LSP permet de comprendre le code, y avoir de l’intellisense, proposer des refactorings, avoir accès à la documentation du code pour l’afficher, etc.
C’est le même système qu’utilise vscode. Une fois qu’un langage a son propre serveur LSP, n’importe quel client LSP peut interagir avec.
Neovim est disponible en GUI⌗
Vous le savez probablement si vous avez déjà ouvert neovim volontairement ou par accident, il est par défaut utilisable via un terminal. Depuis votre terminal préféré, votre shell préféré, simplement démarrez vim
et vous voilà bloquer à vie dans cet éditeur de texte. Ou bien, faites :qa!
pour le fermer.
Moins connu, neovim peut s’employer en mode remote. Cela signifie que, a l’image de vscode, il peut s’exécuter à distance via d’autres clients graphique. Dont un connu : neovide. N’étant pas un utilisateur de neovide, je ne peux pas vous dire si c’est une bonne alternative. Mais je peux vous dire que c’est possible, et que d’autres clients sont possibles.
Mes collègues sont surpris qu’ils puissent ouvrir des fichiers via un double clics dans neovim. Le terminal ainsi que neovim supportent les actions de clics.
Toutefois, neovim n’est pas pour tout le monde, et a plusieurs façon et étape pour l’aborder. Si vous êtes maintenant curieux de découvrir neovim, les prochaines paragraphe sont pour vous.
Partie 2, découvrir neovim⌗
Les motions⌗
Je ne recommande pas neovim à tout le monde, mais je recommande les vim motions à tous.
Nous verrons plus tard dans l’artique comment étendre la configuration et consommer les plugins. Pour l’instant, nous allons voir comment l’utiliser sans le configurer. Cette première partie est dédiée aux vim motions.
less
etman
partagent des motions identiques à vim. Depuis un système unix, ouvrez un manuel viaman
et naviguez viaj
,k
,C-U
,C-D
. Faites une recherche avec/
. Apprenez une fois, appliquez partout.
La navigation dans vim est basée sur des motions. Les motions sont des mouvements que vous pouvez faire avec votre clavier pour vous déplacer dans le texte. Les motions sont basées sur les touches h
, j
, k
, l
pour se déplacer respectivement à gauche, bas, haut, droite. Ces touches sont les touches de base pour se déplacer dans vim. Ce sont les motions les plus populaires. avec gg
et G
, respectivement placez le curseur en début et en fin de fichier. Simple, ça demande un peu d’entrainement, l’apprentissage en vaut la peine.
Ces mouvements, vous pouvez les réutiliser dans d’autres outils comme man
ou less
. Apprenez une fois, appliquez partout.
Lors de longue session de coding, qui implique de lancer régulièrement des tests, ainsi qu’explorer en débug, je préfère aujourd’hui les outils de JetBrains comme Rider ou Goland. Avec tous les outils de jetbrains ainsi que vscode, je peux installer des plugins pour retrouver ces motions. Même si dans des conditions spécifiques, je peux ouvrir vscode ou Rider, les motions sont toujours là pour m’aider.
Pour en savoir plus, un tutoriel est explorable via neovim. Ouvrez l’outil, tapez :Tutor
et prévoyez une heure pour lire et s’entrainer de bout en bout. C’est le meilleur conseil que donnera cet article.
De plus, il y a déjà énormément de contenu, notamment YouTube sur le sujet des motions. Je ne pense pas être capable à travers cet article donner quelque chose de nouveau.
Après tout, vous n’êtes qu’à une seule vidéo Youtube d’apprendre l’IDE de bout en bout.
Les distributions⌗
Découvrir la configuration de neovim demande aussi un temps d’adaptation. Il n’est pas aisé d’installer neovim, et appliquer un plugin en quelques secondes comme vscode. Chaque installation demande un changement dans les fichiers de configurations. Ce système, étant un peu moins accessible que quelques clics dans une fenêtre, ne permet pas de découvrir les plugins les plus populaires rapidement. Pour y arriver, je recommande l’installation d’une distribution qui intègre directement le nécessaire pour être efficace et productif. Voici une liste non-exhaustive :
Ces distributions sont populaires, promeuvent la stabilité, ont une maintenance active, ont une documentation complète, et sont facilement personnalisables. Elles sont un bon point de départ pour découvrir neovim sans devoir intégrer toute la stack de configuration.
Une fois avec une expérience de neovim, un choix s’offre à vous :
- Continuer avec une distribution
- Créer votre propre configuration
Que ce soit via une distribution ou votre propre configuration, enregistrez chaque modification dans un dépôt git. Cela vous permettra de revenir à un état précédent si vous cassez quelque chose, et de partager votre configuration avec d’autres.
Le premier est idéal si vous ne voulez pas configurer vous-même neovim. Si le lua vous rebute, si vous privilégiez consommer un produit consommable immédiatement au lieu de l’adapter finement à vos besoins, ou favorisez la stabilité. Ces distributions existent pour ces raisons. Deux de mes collègues ont choisi cette voie et en sont satisfaits. Dans ce cas, la prochaine section n’est pas pour vous. Voici maintenant mes recommandations pour démarrer votre propre configuration.
Votre propre configuration⌗
Ceci n’est pas pour tous. Configurer neovim demande du temps, de la patience, et de l’expérience. Si vous êtes curieux, si vous aimez apprendre, si vous avez du temps, alors cette section est pour vous.
Même si l’objectif est de créer de bout en bout une configuration personnelle, je recommande quand même par une configuration existante. Cela vous permettra de voir comment les autres ont fait, ce qui est possible, et vous donnera des idées pour votre propre configuration. Notamment pour donner une structure de fichier cohérent, avoir quelques plugins préinstallé, bénéficier d’un plugin manager prêt à l’emploie etc.
Par exemple, vous pouvez utiliser kickstart.nvim qui est populaire pour cet objectif. Le readme indique exactement ce que vous devriez faire : un fork. Lisible de bout en bout, il est idéal pour démarrer votre propre configuration. De plus, la licence associé MIT vous permet de la remplacer par celle qui vous convient, ou même tout simplement la retirée.
Conclusion⌗
Neovim me correspond. À la fois dans mon envie d’automatiser mes actions journalières, dans mes restrictions physiques, j’y trouve un confort que je ne veux pas me séparer.
Aussi, il m’est utile dans des situations délicates où l’ordinateur fournit ne peut pas lancer aisément les outils plus communs comme Visual Studio ou Rider.
Je n’ai pas parlé de la philosophie Unix, de piloter neovim en go, de sa communauté active. Cet article s’est limité à mon expérience personnelle ainsi que quelques tips pour découvrir neovim de votre côté.
A propos de l'auteur
Je m'appelle Mathieu Scolas. Constatant que peu de blogueurs proposent du contenu personnel, constructif et nouveau, ce blog tente de compléter ce manque. Il me permet de partager des guidelines et exprimer des opinions sur le développement d'application. Dans la volonté d'éveiller les lecteurs sur différents sujets, ma façon est de comparer les bonnes pratiques avec les interprétations populaires, ou de présenter des sujets peu évoqués ailleurs. Ce blog me sert aussi de source pour exprimer au mieux des sujets qui méritent un support pour expliquer convenablement les avantages des pratiques, comment les appliquer correctement, et quelles en sont les origines. Retrouvez-moi sur Linkedin et Github.