Explorez l'impact de Bram Moolenaar via Vim : édition modale, flux de travail répétables et habitudes communautaires qui ont façonné la productivité des développeurs pendant des décennies.
Bram Moolenaar a créé Vim comme une amélioration du classique éditeur vi, mais la raison pour laquelle Vim a perduré des décennies n'est pas que technique. Vim est devenu une manière partagée de travailler : une approche pour écrire et transformer du texte qui s'est diffusée dans les équipes, les tutoriels et les projets open source. Après le décès de Bram, beaucoup d'hommages ont insisté sur ce point : Vim n'était pas seulement un logiciel que les gens utilisaient ; c'était quelque chose qu'on apprenait et qu'on emportait dans sa pratique quotidienne.
Quand les développeurs parlent de « culture d'éditeur », ils décrivent plus que des préférences. C'est l'ensemble d'habitudes et de normes qui se forment autour d'un outil :
Cette culture compte parce qu'elle façonne le comportement. Deux personnes peuvent ouvrir le même fichier dans le même éditeur et évoluer à des vitesses complètement différentes — pas par manque de talent, mais par des habitudes pratiquées.
Ceci n'est pas une encyclopédie de commandes. Vous apprendrez plutôt des modèles de flux de travail popularisés par Vim : comment les gens construisent des routines d'édition répétables, réduisent les frictions pour les petits changements et restent orientés dans de grands fichiers.
Vous n'avez pas besoin d'être « un utilisateur de Vim », ni d'avoir un profil technique pour suivre. Nous limiterons le jargon, expliquerons les idées simplement et nous concentrerons sur pourquoi ces habitudes importent — même si vous utilisez un autre éditeur aujourd'hui.
Bram Moolenaar (1961–2023) est indissociable de l'identité de Vim — non pas parce que Vim était un projet d'une seule personne, mais parce qu'il a assuré une gouvernance régulière qui a permis à un outil porté par des bénévoles de rester cohérent pendant des décennies.
Les racines de Vim remontent à la tradition de l'éditeur vi. Bram a commencé le projet à la fin des années 1980 en travaillant sur le Commodore Amiga, initialement comme une version améliorée d'un éditeur de type vi existant. Très vite, Vim a dépassé ses origines : les sorties du début des années 1990 ont élargi les fonctionnalités et la portabilité ; à mesure que Unix, Windows, puis macOS et Linux devenaient des environnements communs, Vim est apparu presque partout.
Cette présence multiplateforme importait. Un outil qui se comportait de façon similaire sur la machine personnelle, les labos universitaires et les serveurs de l'entreprise inspirait confiance — et cette confiance a aidé Vim à devenir un réglage par défaut durable pour professionnels et amateurs.
Les projets open source échouent souvent en douceur quand la coordination devient plus difficile que le codage. La contribution clé de Bram a été le maintien en tant qu'art : revoir des patchs, guider les sorties, garder la documentation et le comportement cohérents, et façonner les normes de collaboration. Beaucoup de contributeurs ont amélioré Vim, mais l'éditeur a conservé une « sensation » reconnaissable parce que quelqu'un gardait l'ensemble aligné.
Vim était aussi connu comme « charityware ». L'idée était simple : si vous trouviez Vim utile, pensez à faire un don aux causes caritatives que Bram soutenait. Ce n'était pas un paywall et ce n'était pas requis pour utiliser l'éditeur ; c'était une invitation à redonner — un signal précoce que la culture logicielle peut inclure la générosité, pas seulement l'efficacité.
L'arc long de Vim est, en fin de compte, l'histoire de la continuité : un éditeur resté pertinent non pas en courant après les modes, mais en évoluant prudemment tout en préservant sa communauté — et ses valeurs.
L'idée la plus distinctive de Vim est les modes : les mêmes touches font des choses différentes selon ce que vous cherchez à faire. Cela paraît étrange jusqu'à ce qu'on réalise que cela reflète la façon dont vous travaillez déjà — parfois vous pensez à un changement, parfois vous tapez du texte.
Normal mode sert aux actions d'édition : déplacer, supprimer, changer, rechercher. Vous n'êtes pas en train d'« écrire » ; vous donnez des directives.
Insert mode sert à taper des caractères dans le document — ce que la plupart des éditeurs traitent comme le mode par défaut.
Visual mode sert à sélectionner du texte pour pouvoir agir dessus (indentation, suppression, remplacement, copie).
Un exemple simple :
dd pour supprimer une ligne entière.i pour entrer en Insert mode et taper du contenu.Esc pour revenir en Normal mode.v pour commencer le Visual mode, déplacez‑vous pour sélectionner, puis appuyez d pour supprimer la sélection.Quand tout est toujours en mode saisie, vous mélangez deux tâches différentes : composer des mots et effectuer des modifications. L'édition modale les sépare.
En Normal mode, vos mains ne sont pas constamment « prêtes » à insérer des caractères par accident. À la place, vous êtes délibéré : Quel changement je veux faire ? Supprimer ceci, changer cela, aller là, répéter. Insert mode devient un moment concentré : Maintenant j'ajoute du texte.
Avec le temps, cela ressemble moins à se battre contre l'éditeur et plus à donner de petites instructions claires.
Les points de douleur initiaux sont prévisibles :
x ou dd.)i.)Reformulez les modes comme des états d'intention. Normal mode n'est pas « ne pas travailler » — c'est le mode où vous éditez volontairement. C'est l'habitude que l'édition modale enseigne : d'abord des changements délibérés, ensuite la saisie.
Le « super‑pouvoir » de Vim n'est pas un énorme menu de fonctionnalités — c'est la manière dont de petites commandes s'emboîtent. Plutôt que de mémoriser un raccourci distinct pour chaque situation, vous apprenez quelques blocs de base et les combinez.
Pensez l'édition comme un verbe appliqué à un morceau de texte.
En langue Vim, les verbes sont des opérateurs (comme d pour delete, c pour change), et les objets sont des motions/objets texte (comme w pour mot, ) pour phrase, i\" pour à l'intérieur des guillemets).
Quelques combinaisons montrent l'intérêt :
cw — « change » + « word ». Pas besoin de sélectionner d'abord ; vous énoncez votre intention.di\" — « delete » + « inside quotes ». Les guillemets restent et seul le contenu est supprimé.v puis quelque chose comme i{ — sélection visuelle + « à l'intérieur des accolades » pour prendre ce qui est dans un bloc { ... }.L'intérêt n'est pas d'amasser des astuces, mais de construire un modèle mental où les commandes sont prévisibles.
La composabilité récompense la précision et la consistance. Quand le même verbe fonctionne avec de nombreux objets, vous faites moins d'hypothèses d'édition, annulez moins et gardez un esprit plus calme dans des fichiers inconnus. La vitesse suit souvent — non pas parce que vous cherchez la rapidité, mais parce que vous répétez une manière fiable de penser le texte.
Une idée très pratique de Vim est que l'édition ne devrait pas être une performance unique. Si vous pouvez décrire une modification une fois, vous devriez pouvoir la répéter — de manière fiable — sur la ligne suivante, le paragraphe suivant ou le fichier suivant. C'est là que la « vitesse » devient moins une question de frappe rapide que de réduction de la fatigue décisionnelle.
La commande point (.) rejoue votre dernier changement. Ça paraît petit, mais cela vous encourage à faire des éditions en morceaux propres et répétables.
Exemple : vous transformez foo en foo() sur une ligne en insérant des parenthèses. Sur les occurrences suivantes, vous pouvez souvent déplacer le curseur au bon endroit et appuyer sur . au lieu de refaire toute l'insertion. L'habitude : faites une édition consciencieusement, puis répétez.
Les macros vous permettent d'enregistrer une suite de frappes et de la rejouer. Conceptuellement, c'est comme dire : « Quand tu vois ce motif, applique ces étapes. » Un usage simple et sûr est le formatage d'une liste :
- en début de plusieurs lignesÉvitez l'automatisation excessive quand le texte n'est pas uniforme. Si chaque ligne nécessite une décision différente, une macro peut créer des erreurs subtiles plus vite que vous ne les repérez.
La recherche sert déjà à la navigation ; la substitution est recherche + action. Pensez simplement : « Trouve cette chaîne, remplace par celle‑ci », comme renommer temp en draft dans un fichier. Si le changement peut affecter du texte non lié, confirmez chaque remplacement plutôt que d'appliquer aveuglément.
La leçon plus large : construisez des recettes répétables pour les modifications courantes. Avec le temps, votre flux de travail devient une bibliothèque de petits mouvements fiables plutôt qu'une série de corrections ad hoc.
Le style clavier d'abord de Vim n'est pas un test de pureté, et il ne fait pas de quelqu'un un « meilleur » développeur. Le but est plus simple : chaque fois que vous atteignez la souris ou le trackpad, vous coupez une petite boucle d'attention — les mains quittent la position de base, les yeux cherchent un curseur, et votre esprit change de « quoi » à « où ». Réduire ces interruptions facilite la concentration sur le problème à résoudre.
Vim vous pousse à naviguer dans le texte comme vous y pensez :
w, b, e, )), quand vous façonnez du texte ou des identifiants.0, ^, $, gg, G), quand la structure compte./, ?, n, N), quand vous chassez une intention.:e, :b, sauts via tags/LSP), quand le changement s'étend au code.Avec le temps, « aller à la chose » devient un réflexe plutôt qu'une mini‑décision à chaque fois.
Le gain réel n'est pas de gagner quelques millisecondes ; c'est d'éliminer l'hésitation. Des gestes petits et répétables — changer « à l'intérieur des guillemets » ou supprimer « jusqu'à la virgule suivante » — deviennent des raccourcis physiques pour des modifications fréquentes. Quand ces patterns s'ancrent, vous dépensez moins d'énergie mentale pour manipuler l'éditeur et plus pour choisir le bon changement.
Le flux clavier peut réduire les déplacements du poignet pour certains, mais augmenter la charge des doigts pour d'autres. Les bénéfices ergonomiques varient selon la personne, le clavier et même le choix des commandes. La culture de personnalisation de Vim est utile ici : remappez les touches inconfortables, doser l'utilisation et privilégier le confort sur l'idéologie. L'objectif est un focus durable, pas de l'endurance.
Vim a toujours encouragé la prise en main. Plutôt que de considérer l'éditeur comme un produit scellé, il le traite comme un établi — quelque chose que vous ajustez jusqu'à ce qu'il corresponde à votre façon de penser.
Un vimrc est le fichier de configuration de Vim. C'est là que vous définissez vos valeurs par défaut : le comportement des tabulations, le retour à la ligne, ce que montre la barre d'état, et plus. Beaucoup de développeurs conservent ces réglages sous contrôle de version dans leurs « dotfiles », pour que l'éditeur soit familier sur n'importe quelle machine.
Ce n'est pas seulement de la personnalisation pour elle‑même. C'est une norme culturelle parce que les petits choix par défaut s'accumulent : moins de frictions, moins de surprises et moins de « pourquoi Vim fait‑il ça ? ».
Le moyen le plus sûr d'avoir un setup en pagaille est d'installer dix plugins avant de comprendre quel problème vous résolvez. Une approche plus saine :
Traitez votre vimrc comme un carnet d'atelier, pas comme un tiroir à bazar.
Un mapping est un raccourci : vous appuyez une combinaison et Vim exécute une séquence plus longue. De bons mappings réduisent la répétition ; de mauvais mappings rendent Vim incohérent.
Un plugin ajoute des fonctionnalités : sélecteurs de fichiers, aides Git, meilleur support linguistique. Les plugins peuvent être excellents, mais ils ajoutent aussi des pièces mobiles, du temps de démarrage et de nouveaux comportements à apprendre.
Avant d'ajouter des extras, familiarisez‑vous avec quelques réglages de base :
Quand cette base devient naturelle, les plugins deviennent une amélioration réfléchie — pas un substitut à l'apprentissage de Vim lui‑même.
La culture de Vim ne commence pas avec les plugins ou les raccourcis — elle commence par l'apprentissage. Bram Moolenaar considérait la documentation comme partie du produit, et cette attitude a façonné la manière dont on enseigne Vim : pas comme un ensemble de secrets, mais comme une compétence qu'on peut développer progressivement.
:help de Vim n'est pas une après‑pensée ; c'est une carte. Il récompense la curiosité par une structure — sujets, références croisées et exemples qui supposent que vous allez explorer.
Quelques habitudes simples transforment « je suis bloqué » en « je peux trouver » :
:help {topic} (ou :h) pour aller directement vers un concept comme :h motion ou :h visual-modeCTRL-] pour suivre les liens dans l'aide, et CTRL-T pour revenir:helpgrep {word} pour chercher dans la doc quand vous ne connaissez pas le terme exactCe modèle évolue bien : une fois que vous savez comment poser des questions à l'éditeur, vous dépendez moins de la mémorisation.
Le mentorat Vim ressemble souvent à de petites interventions respectueuses : un mapping, un mouvement, un ajustement de flux. La règle non écrite est « partir des habitudes de chacun ». Il est courant de donner un conseil et d'ajouter, clairement, « Si ton éditeur te va déjà, c'est parfait. »
D'autres normes pratiques :
Le savoir Vim circule via des objets légers : fiches mémo, présentations éclair, templates de dotfiles et petits dépôts « starter ». Les meilleurs expliquent pourquoi une habitude aide, pas seulement quoi taper.
Certaines personnes n'utilisent Vim que pour des petites éditions en SSH ; d'autres en font leur environnement quotidien. La culture Vim fonctionne quand elle considère les deux usages comme légitimes — et trace un chemin clair entre eux.
La réputation de Vim se base souvent sur la « puissance », mais sa véritable valeur apparaît dans les moments ordinaires : un message de commit à clarifier, un fichier de config en production à modifier en sécurité, ou une session de pairing où l'on veut des modifications précises et faciles à expliquer.
Édition de commits : Beaucoup de développeurs configurent Git pour ouvrir Vim pour les messages de commit et les rebasages interactifs. L'édition modale convient ici parce que vous passez la plupart du temps à lire et réorganiser du texte, pas à insérer du contenu. Normal mode devient un mode de relecture : sautez entre les phrases, réordonnez des lignes et corrigez de petites erreurs sans atteindre la souris.
Corrections rapides sur serveur : Quand vous SSH sur une machine et devez patcher une config, Vim est souvent déjà disponible. L'objectif n'est pas la personnalisation — c'est la confiance : trouvez le bon bloc, changez seulement ce que vous souhaitez, enregistrez et quittez proprement.
Pairing : Vim peut être étonnamment adapté au pairing car les actions sont explicites. Dire « supprime ce paragraphe » ou « change à l'intérieur des guillemets » se traduit par des commandes claires, et votre partenaire apprend en observant.
Vim brille quand on le traite comme un outil dans une chaîne. Vous pouvez chercher avec ripgrep/grep, ouvrir les résultats et faire des éditions ciblées — sans transformer l'éditeur en IDE complet.
Par exemple, une boucle commune : lancez une recherche dans le terminal, ouvrez le fichier à la correspondance, éditez, puis relancez les tests. C'est « faire une chose bien » appliquée au quotidien : le terminal trouve ; Vim édite ; votre runner de tests vérifie.
git config --global core.editor \"vim\"C'est ainsi que Vim monte en puissance : pas en ajoutant de la complexité, mais en rendant les éditions courantes rapides, réversibles et cohérentes entre environnements.
Vim a de réels avantages — mais il attire aussi des mythes. Les opinions les plus véhémentes viennent parfois de ceux qui l'ont essayé un week‑end, ou de fans qui en font un insigne. Une manière plus utile de l'envisager : Vim est un ensemble d'idées d'interaction (surtout l'édition modale) qui peuvent s'adapter à de nombreux flux, mais ce n'est pas automatiquement le meilleur choix pour chaque personne ou équipe.
« La courbe d'apprentissage est trop raide. »
C'est raide au début parce que les bases semblent différentes : les modes, l'opérateur + mouvement et l'accent sur les verbes d'édition plutôt que sur des boutons. La courbe s'adoucit si vous apprenez un petit noyau et l'utilisez quotidiennement ; mais si vous ouvrez Vim seulement occasionnellement, la mémoire musculaire ne se forme pas.
« Ce n'est pas découvrable. »
En partie vrai. Vim récompense la lecture de :help, mais l'interface n'affiche pas constamment ses fonctionnalités. La découvrabilité existe — mais ailleurs : dans l'aide intégrée, les tutoriels et une culture de partage de petits patterns.
« Chaque Vim est différent. »
Vrai aussi. Les configurations varient, les plugins changent le comportement et les paramètres par défaut diffèrent selon les environnements. Cela peut frustrer lors du pairing ou du changement de machine. Les équipes résolvent souvent cela par des réglages minimaux partagés (ou en s'entendant sur un « Vim vanilla ») plutôt qu'en essayant de tout standardiser.
Vim peut mal s'accorder quand les contraintes d'équipe exigent un flux IDE spécifique, quand le temps d'onboarding est limité, ou quand des besoins d'accessibilité rendent certaines interactions à forte intensité de touches inconfortables. Les préférences comptent aussi : certain·e·s réfléchissent mieux dans une interface visuelle avec de riches outils de refactorisation, et ils seront plus efficaces là‑dessus.
Une approche pragmatique : choisissez l'outil qui soutient le travail que vous faites réellement : corrections rapides sur SSH, édition de configs, programmation quotidienne, ou collaboration dans un environnement standardisé.
Deux pièges attirent les apprenants motivés :
D'abord, le réglage sans fin — passer plus de temps à customiser des plugins qu'à utiliser l'éditeur. Ensuite, la chasse aux raccourcis — accumuler des commandes sans construire d'habitudes répétables. Si vous voulez que Vim vous rende plus rapide, concentrez‑vous sur des workflows que vous répétez chaque semaine, et automatisez seulement ce que vous pouvez nommer clairement.
Règle saine : si un changement n'économise pas de temps ou ne réduit pas d'erreurs dans la semaine qui suit, remettez‑le.
Vim est le plus utile quand il vous aide à rester en flux, éditer avec intention et construire des patterns répétables. Si un autre éditeur fait mieux cela pour vous — ou pour votre équipe — choisissez‑le sans culpabilité. Le but n'est pas « utiliser Vim », c'est produire du bon travail avec moins de friction.
Apprendre Vim est durable quand vous le traitez comme l'acquisition de quelques habitudes fiables — pas la collecte de commandes obscures. L'objectif est de se sentir calme et capable en éditant, avant même de se sentir « rapide ».
Consacrez 10–15 minutes par jour, et utilisez Vim pour une tâche réelle (même minime). Prenez des notes sur ce qui vous a gêné et sur ce qui est devenu plus fluide.
Semaine 1 : confort et sécurité
Concentrez‑vous sur ne pas rester coincé. Entraînez‑vous à ouvrir des fichiers, enregistrer, quitter et annuler.
Semaine 2 : navigation et recherche
Commencez à vous déplacer sur des sauts plus grands et à compter sur la recherche pour aller n'importe où rapidement.
Semaines 3–4 : flux d'édition
Ajoutez un petit ensemble de patterns « éditer + répéter » : changer/supprimer/yanker, répéter avec ., et une macro basique pour quelque chose que vous faites souvent.
:w, :q, :wq, :q!, plus u (undo) et \u003cC-r\u003e (redo)w, b, e, 0, $, gg, G, et un peu de f{char}/pattern, n / N, et :%s/old/new/g (essayez sans options d'abord)Éditez un README : corrigez des titres, réordonnez des puces et réécrivez un paragraphe sans toucher la souris.
Refactorez un petit fichier : renommez une variable avec recherche + remplacement, extrayez quelques lignes et réindentez.
Tenez un journal dans Vim : une courte entrée par jour. La répétition construit le confort plus vite que des exercices « difficiles ».
Suivez le confort (moins de panique) et la consistance (moins d'interruptions de contexte), pas la vitesse brute. Si vous pouvez prédire ce qu'une commande fera — et récupérer quand vous vous trompez — vous apprenez la part qui dure.
L'impact durable de Bram Moolenaar n'est pas seulement d'avoir créé l'éditeur Vim : il a montré ce qu'est la gouvernance patiente. Pendant des décennies il a revu des patchs, organisé des sorties, répondu aux questions et gardé une « sensation » claire du logiciel : efficace, cohérent et indulgent une fois qu'on apprend sa grammaire. La tradition « charityware » de Vim reflétait aussi ses valeurs : le logiciel comme bien public, et la maintenance comme un travail réel qui mérite du soin.
Vim récompense l'attention aux actions petites et répétables. La grande leçon n'est pas une commande précise, mais un état d'esprit : investir dans des habitudes qui réduisent la friction. Quelques secondes gagnées par modification ne semblent pas beaucoup — jusqu'à ce que cela devienne la manière par défaut de penser en écrivant du code, des notes ou de la prose. Avec le temps, l'éditeur devient moins un outil qu'on pilote et plus un médium à travers lequel on travaille.
De façon intéressante, cette logique « d'intention d'abord » se transpose bien aux flux plus récents. Si vous développez via une interface conversationnelle — par exemple avec des approches assistées par IA — les mêmes habitudes s'appliquent : formuler le changement comme une instruction claire et répétable, itérer par petites étapes, et compter sur des filets de sécurité (snapshots, rollback) plutôt que de tout risquer en un seul gros rewrite.
Vim enseigne aussi l'art social : apprendre en public, partager des dotfiles avec soin, rédiger des rapports de bug clairs et accueillir les débutants avec patience. Des normes saines rendent un outil « difficile » plus accessible. Si vous voulez approfondir, la documentation intégrée et les ressources communautaires font partie du produit, pas des extras.
Avant de fermer cet article, choisissez un petit changement de flux que vous essayerez cette semaine : remappez une touche que vous atteignez trop souvent, pratiquez un pattern d'édition répétable, ou notez un petit défaut personnel dans votre vimrc.
Enfin, une note respectueuse : les projets open source vivent quand les utilisateurs deviennent des soutiens — par des dons, de la documentation, des issues soignées, de la revue de code, ou simplement en disant merci. L'héritage de Bram rappelle que les personnes qui maintiennent nos outils comptent autant que les outils eux‑mêmes.
La culture d'éditeur est l'ensemble partagé d'habitudes, de raccourcis, de vocabulaire et de rituels de mentorat qui se développe autour d'un outil.
Dans le cas de Vim, cela inclut des éléments comme la façon de penser « opérateur + mouvement », l'échange d'astuces lors de sessions de pairing, et le fait de considérer la configuration (un vimrc) comme partie intégrante du flux de travail — pas comme un détail secondaire.
L'édition modale sépare les intentions :
Cela réduit les modifications accidentelles et fait des changements des instructions claires (supprimer/changer/déplacer), la saisie intervenant uniquement quand vous le souhaitez.
La « composabilité » de Vim crée une grammaire prévisible : un verbe (supprimer/changer/yanker) appliqué à une cible (mot, phrase, à l'intérieur de guillemets, jusqu'à la fin de la ligne).
Exemples :
cw = changer un motdi\" = supprimer à l'intérieur des guillemetsVous apprenez moins de concepts de base et vous les réutilisez dans de nombreuses situations, au lieu de mémoriser un raccourci pour chaque scénario.
Utilisez . quand vous faites le même type de changement de manière répétée.
Un flux pratique :
. pour répéter.Cela vous pousse à faire des éditions en « blocs » propres et répétables, ce qui réduit souvent les erreurs et le retravail plus qu'il n'augmente la vitesse brute.
Les macros sont utiles quand le texte est cohérent et que les étapes sont mécaniques.
Bons usages :
Risque : quand chaque ligne demande un jugement différent, une macro peut produire des erreurs rapides et difficiles à voir. Dans ces cas, préférez la recherche + confirmation ou des répétitions plus petites et sûres.
Un vimrc est le fichier de configuration de Vim où l'on définit les valeurs par défaut (indentation, comportement de recherche, options d'affichage, etc.).
Approche pratique :
Considérez-le comme un petit « atelier » portable, pas comme un fourre‑tout de réglages aléatoires.
Commencez par une base minimale (indentation, paramètres de recherche, numéros de ligne, thème lisible). N'ajoutez un plugin que si vous savez précisément quel problème il résout.
Règle utile : si un plugin n'économise pas de temps ou ne réduit pas d'erreurs cette semaine, reportez son installation. Cela évite que la « chasse aux plugins » remplace l'apprentissage et les habitudes productives.
Pour un usage occasionnel (comme en SSH), privilégiez un petit kit de survie :
Vim est souvent utilisé pour les messages de commit et les rebasages interactifs parce qu'on passe beaucoup de temps à lire et réarranger du texte.
Un réglage simple :
git config --global core.editor \"vim\"Même une navigation et une recherche basiques rendent la relecture et la correction des messages de commit plus contrôlées qu'une approche purement souris.
Vim peut être plus confortable pour certaines personnes (moins de déplacements de souris), mais il peut aussi augmenter la sollicitation des doigts selon la morphologie, le clavier et les habitudes.
Usage durable :
Le meilleur flux de travail est celui que vous pouvez maintenir sans douleur.
i, Esc, :w, :q, :wq, :q!u, Ctrl-r/pattern, puis n/NL'objectif est la confiance et la possibilité de revenir en arrière, pas une configuration complète.