🧙🏻 👏🏿 📺 Histoire de Vim et un guide pour son utilisation efficace ✨ 🥗 👩🏽

Note du traducteur: il s'agit de la première partie de l'article monumental (en fait monumental) sur Vim et ses capacités du développeur de Minneapolis et de l'auteur du projet PostgREST, Joe begriffs Nelson.

La première partie de l'article est consacrée à se familiariser avec l'histoire de Vim en tant qu'éditeur, et l'auteur parle d'un certain nombre de faits intéressants sur les capacités de Vim. Dans la deuxième partie de la traduction, tous les jetons et hacks de vie que Joe a décidé de partager avec le public seront concentrés, là le récit, en tant que tel, s'estompe et il ne reste qu'un ensemble de lignes directrices pour l'action. Comme le texte original a des dimensions totalement inacceptables, nous avons divisé cette histoire en deux articles de taille approximativement égale. Aujourd'hui est la première de deux publications. Bonne lecture.

Cet article est basé sur des recherches sur l'histoire de Vim et sur la lecture de son guide d'utilisation. J'espère que ces notes vous aideront à découvrir (ou à redécouvrir?) Les fonctionnalités de base de cet éditeur, ainsi qu'à vous permettre d'abandonner l'utilisation des fichiers vimrc avertis et d'utiliser les plugins de manière plus réfléchie.

Les références

Pour aller au-delà des sujets habituels, je recommanderais d'obtenir une copie papier de ce manuel et une référence de poche volumineuse. Je n'ai pas pu trouver une copie imprimée du guide de l'utilisateur de Vim, donc à la fin je viens d'imprimer le fichier PDF fourni avec l'éditeur en utilisant printme1.com. $VIMRUNTIME/doc/usr_?? il avec un logiciel dans $VIMRUNTIME/doc/usr_?? . En tant que liste pratique de commandes, je peux vous conseiller le livre de référence «Vi and Vim Editors Pocket» .

Table des matières

L'histoire
Hiérarchie de configuration
Plugins tiers
Sauvegardes et ristournes
Inclure et chemin
Édition et compilation d'une boucle
Diffs et patchs
Tampon d'entrée / sortie
Types de fichiers
N'oubliez pas la souris
Divers

L'histoire

Naissance vi

Les commandes et fonctions Vi existent depuis plus de cinquante ans, à commencer par l'éditeur QED. Voici sa chronologie:

1966: QED (Quick Editor) au Berkeley Timesharing System
Juillet 1969: avec son aide, ils ont atterri sur la lune (enfin, pour référence)
Août 1969: QED → ed at AT&T
1976 fév: ed → em («Editor for Mortals») au Queen Mary's College
1976: em → ex ("EXtended") à l'Université de Californie, Berkeley
1977 Oct: ex reçoit le mode visuel, vi - terminal texte

Si vous lisez le manuel QED et ex , vous pouvez trouver des similitudes entre eux. Les deux éditeurs utilisent une grammaire similaire pour indiquer et travailler avec des plages de lignes.

Des éditeurs tels que QED ed et em ont été conçus pour les terminaux d'impression, qui étaient pour la plupart des machines à écrire électriques ordinaires avec un modem connecté. De tels terminaux "à copieur complet" affichaient des commandes sur papier et, évidemment, une fois entrés, il était impossible de faire des corrections. Par conséquent, le processus d'édition consistait à éditer manuellement les commandes utilisateur sur papier, puis à les saisir à nouveau.

En 1976, des terminaux vidéo, par exemple ADM-3A, sont apparus. Un «mode ouvert» a été ajouté à l'éditeur Ex, ce qui a permis d'éditer via un terminal vidéo sur une seule page. Un mode visuel a été ajouté pour s'orienter sur les lignes du terminal à l'aide du curseur. Le mode visuel a été activé par la commande «vi» et a constamment mis à jour le fichier affiché à l'écran, tout en conservant le positionnement de la ligne de commande en bas de l'écran. Fait intéressant: des flèches ont été placées sur les touches h, j, k, l de l'ADM-3A, ce qui nous a permis de déplacer le curseur sur vi.

Vous pouvez en savoir plus sur cette transition de ed à ex / vi dans une interview avec Bill Joy . Dans ce document, il parle de la façon dont il a créé ex / vi et de certaines choses qui l'ont finalement déçu.

Classic vi est juste un alter est ex. Les deux sont représentés par le même fichier binaire, qui peut être exécuté à la fois en ex-mode et en vi-mode, selon le nom du fichier exécutable. L'héritage de toute cette histoire est que ex / vi «se déplie» lorsqu'il est utilisé, ne nécessite presque pas de ressources système et peut fonctionner dans des conditions de bande passante limitée. Il est également disponible sur la plupart des systèmes existants et est entièrement décrit dans POSIX.

Vi à vim

Dérivé d'ed, l'éditeur ex / vi était la propriété intellectuelle d'AT & T. Pour utiliser vi sur des plateformes autres qu'Unix, les gens devaient écrire des clones qui avaient une base de code source différente.

En voici quelques uns:

nvi - 1980 pour 4BSD
calvin - 1987 pour DOS
vil - 1990 pour DOS
stevie - 1987 pour Atari ST
elvis - 1990 pour Minix et 386BSD
vim - 1991 pour Amiga
viper - 1995 pour Emacs
elwin - 1995 pour Windows
lemmy - 2002 pour Windows

Nous allons nous concentrer sur le clone du centre de la liste - Vim. Bram Mulenaar voulait utiliser vi sur Amiga et a commencé à porter avec Atari et à développer le clone vi stevie. Et il a nommé sa version du port «Vi Imitation». Si vous voulez en savoir plus sur ce processus, regardez son interview pour Free Software Magazine.

Dans la version 1.22, Vim a été renommé «Vi IMproved», ce qui indique la supériorité de la copie sur l'original. Voici un graphique des principales versions suivantes avec des descriptions de certaines fonctionnalités:

Pour plus d'informations sur chaque version, l'aide doit être utilisée, par exemple, pour vim8. Pour voir les mises à jour prévues, ainsi qu'une liste des erreurs connues, vous devez vous tourner vers todo.txt.

Par exemple, la huitième version incluait une prise en charge des travaux asynchrones en raison de la pression sur le projet de NeoVim. Les développeurs de ce dernier souhaitaient lancer le débogage et REPL pour les scripts Web directement dans l'éditeur.

Généralement, Vim est superportable. Adaptant toute l'histoire de son existence pour travailler sur des plateformes complètement différentes, cet éditeur a été contraint de rester dans le cadre de la culture «facile» du codage. Vim fonctionne sur OS / 390, Amiga, BeOS et BeBox, Macintosh Classic, Atari MiNT, MS-DOS, OS / 2, QNX, RISC-OS, BSD, Linux, OS X, VMS et MS-Windows. Vous pouvez compter sur Vim n'importe où et ne vous souciez pas de l'équipement que vous utilisez.

À la fin du chemin vi original, en 2002, le code source ex / vi était toujours publié sous la licence de logiciel libre BSD. Les sorciers sont disponibles sur ex-vi.sourceforge.net .

Mais passons aux choses sérieuses. Avant de commencer à analyser Vim, il est utile de savoir comment il organise et lit ses fichiers de configuration.

Hiérarchie de configuration

Auparavant, je croyais à tort que Vim obtient tous ses paramètres et scripts uniquement à partir du fichier .vimrc. La visualisation de référentiels de «fichiers dot» aléatoires ne peut que renforcer cette opinion. Très souvent, les gens téléchargent des fichiers .vimrc monstrueux par essence, dont la tâche est de contrôler tous les aspects de l'éditeur. Ces énormes configurations sont aussi parfois appelées «distributions vim».

En fait, Vim a une structure soignée dans laquelle .vimrc n'est qu'un des nombreux «points d'entrée». En fait, vous pouvez vous-même demander à Vim quels scripts il charge. Pour ce faire, modifiez du code source pour un projet aléatoire sur votre machine, téléchargez-le puis exécutez la commande

 :scriptnames

Cette liste mérite d'être lue. Essayez de deviner ce que font ces scripts et notez les répertoires dans lesquels ils se trouvent.

La liste était plus longue que prévu? Si vous avez installé de nombreux plugins, l'éditeur a beaucoup à faire. Vérifiez qu'il ralentit au démarrage en exécutant la commande de création start.log suivante:

 vim --startuptime start.log name-of-your-file

Comparez simplement la vitesse de démarrage de Vim:

 vim --clean --startuptime clean.log name-of-your-file

Pour déterminer quels scripts doivent être chargés au démarrage ou pendant le chargement de la mémoire tampon, vous devez vérifier le chemin d'exécution Vim. Ce chemin est représenté par une liste de répertoires séparés par des virgules, chacun contenant une structure commune. Vim vérifie ces structures dans chaque répertoire pour trouver ses scripts de démarrage. Les répertoires sont traités strictement dans l'ordre dans lequel ils se trouvent dans la liste.

Vérifiez le chemin d'exécution sur votre système via cette commande:

 :set runtimepath

Mon système contient les répertoires suivants spécifiés par défaut pour la vérification runtimepath. Ils n'existent pas tous, mais Vim essaiera toujours d'y accéder et vérifiera le contenu s'ils sont toujours en place:

~/.vim
Répertoire personnel, conçu pour les profils créés.

/usr/local/share/vim/vimfiles
Répertoire Vim à l'échelle du système, pour les profils avec des privilèges d'administrateur système.

/usr/local/share/vim/vim81
Aka $ VIMRUNTIME, pour les fichiers distribués avec Vim.

/usr/local/share/vim/vimfiles/after
Dans le répertoire Vim à l'échelle du système, il y a aussi le répertoire after. Il est destiné à ajouter les paramètres personnels de l'administrateur système «par défaut».

~/.vim/after
Le répertoire «après» du répertoire personnel. Ceci est nécessaire pour que les configurations personnelles n'annulent pas ou ne chevauchent pas les paramètres à l'échelle du système ou «par défaut».

En général, les répertoires sont traités dans le même ordre dans lequel ils sont écrits dans start.log, une exception n'est faite que pour «après». Celui-ci est toujours en fin de liste et est traité en dernier.

Lors du traitement de chaque répertoire, Vim y recherche des sous-dossiers avec des noms spécifiques. Pour en savoir plus à ce sujet, consultez l'aide runtimepath. Voici une brève description de ceux que nous examinerons plus loin dans le texte:

plugin /
Ici se trouvent les fichiers de script Vim qui sont automatiquement chargés lors de la modification de tout type de fichier. Ils sont également appelés «mondiaux».

autoload /
(A ne pas confondre avec "plugin"). Ces scripts de démarrage contiennent des fonctions qui ne sont resserrées qu'à la demande d'autres scripts.

ftdetect /
Scripts pour déterminer les types de fichiers. Dans leur travail, ils s'appuient sur l'extension, l'emplacement ou le contenu interne du fichier.

ftplugin /
Scripts exécutés lors de la modification de fichiers d'un type connu.

compiler /
Détermine comment exécuter divers compilateurs ou vérifications de peluches et comment analyser leur sortie. Il peut être divisé entre plusieurs plugins ft en même temps. Le compilateur n'est pas exécuté automatiquement et doit être appelé par une commande.

pack /
Un conteneur pour les packages natifs Vim 8, le successeur de la gestion des packages de type Pathogen. Il a son propre système d'emballage, ne nécessite pas de code tiers pour fonctionner.

Et enfin, ~ / .vimrc est un piège pour les paramètres généraux de l'éditeur. Utilisé pour configurer les paramètres par défaut, qui peuvent être attribués à un type de fichier spécifique. Pour afficher la liste entière, vous pouvez sélectionner .vimrc et exécuter la commande d'options.

Plugins tiers

Les plugins ne sont que des scripts Vim, pour lesquels il suffit de les placer aux bons endroits dans le runtimepath. En général, le processus d'installation est extrêmement simple: il suffit de télécharger le (s) fichier (s). Le problème est que certains plugins sont assez difficiles à mettre à jour ou à supprimer, car ils sont dispersés dans différents sous-répertoires et obstruent les chemins d'exécution avec leurs scripts. Autrement dit, à la fin, il est difficile de déterminer quel fichier appartient à quel plugin.

Pour résoudre ce problème, les «gestionnaires de plugins» ont commencé à se développer. Sur vim.org, il y avait un registre de plugins au moins jusqu'en 2003 inclus (si l'archive ne ment pas). Cependant, les «gestionnaires de plugins» en tant qu'entités ne sont entrés dans la mode qu'en 2008.

Ces outils ajoutent des répertoires spéciaux pour les plugins pour suivre les chemins d'exécution et organiser les balises par lesquelles les plugins peuvent être suivis. La plupart des gestionnaires récupèrent également les mises à jour des plugins depuis le réseau.

Ci-dessous, j'ai construit des gestionnaires de plugins en fonction de la chronologie de leur occurrence. Basé sur les plages de dates de sortie de la première et de la dernière version. S'il n'y avait pas de versions officielles, j'ai pris comme base les premières dates de sortie et la dernière mise à jour.

Mars 2006 - Juil 2014: Vimball
Oct 2008 - Dec 2015: Pathogène
Août 2009 - déc 2009: Vimana
Déc 2009 - déc 2014: VAM
Août 2010 - Nov 2010: Jolt
Oct 2010 - Nov 2012: tplugin
Octobre 2010 - février 2014: Vundle
Mar 2012 - Mar 2018: vim-flavour
Avril 2012 - mars 2016: NeoBundle
Janvier 2013 - août 2017: infect
Fév 2013 - août 2016: vimogen
Oct 2013 - Jan 2015: dégroupage vim
Déc 2013 - juil 2015: Vizardry
Fév 2014 - Oct 2018: vim-plug
Jan 2015 - Oct 2015: facilitateur
Août 2015 - avril 2016: Vizardry 2
Janvier 2016 - juin 2018: dein.vim
Sept 2016 - Présent: originaire de Vim 8
Fév 2017 - Sept 2018: minpac
Mars 2018 - mars 2018: autopac
Février 2017 - juin 2018: pack
Mars 2017 - sept. 2017: vim-pck
Sept 2017 - Sept 2017: pack vim8
Sept 2017 - Mai 2019: volt
Sep 2018 - Feb 2019: vim-packager
Fév 2019 - Fév 2019: plugpac.vim

La première chose à laquelle vous devez prêter attention dans la liste ci-dessus est la grande variété. La seconde - chacun des outils présentés «vit» depuis environ quatre ans, puis, très probablement, se démode.

Le chemin de moindre résistance dans la gestion des plugins est simplement d'utiliser la fonctionnalité intégrée de Vim 8, qui ne nécessite pas de récupérer un code tiers. Voyons comment procéder.

Pour commencer, créez deux répertoires dans votre runtimepath: opt et start.

 mkdir -p ~/.vim/pack/foobar/{opt,start}

Faites attention à l'espace réservé «foobar» (le nom peut être changé). Il classe entièrement tous les packages qui entrent. La plupart des utilisateurs transfèrent simplement tous leurs plugins dans une seule catégorie et, en général, c'est normal. Choisissez n'importe quel nom que vous aimez; Je continuerai à utiliser foobar. En théorie, vous pouvez également créer plusieurs catégories, par exemple ~/.vim/pack/navigation et ~/.vim/pack/linting . Veuillez noter que Vim ne reconnaît pas la duplication entre les catégories et télécharge les doublons deux fois s'ils existent.

Les packages dans "start" sont chargés automatiquement, tandis que les packages dans "opt" ne sont pas chargés tant qu'ils ne proviennent pas de Vim en utilisant la commande :packadd . Cette option est bonne pour les packages rarement utilisés et est prise en charge par Vim prête à l'emploi, sans avoir à exécuter de scripts. Notez que :packadd pas d'équivalent pour décharger les paquets.

Pour revoir cet exemple, nous ajouterons le plugin de recherche floue ctrlp à opt. Téléchargez et décompressez sa dernière version sur:

 curl -L https://github.com/kien/ctrlp.vim/archive/1.79.tar.gz \ | tar zx -C ~/.vim/pack/foobar/opt

Cette commande créera le ~ / .vim / pack / foobar / opt / ctrlp.vim-1.79 package prêt à l'emploi. Revenez à vim et créez les pointeurs de balises d'aide (index helptags) pour le nouveau package:

 :helptags ~/.vim/pack/foobar/opt/ctrlp.vim-1.79/doc

Cette commande créera un fichier appelé «balises» dans le dossier avec les tris de packages, qui rendra les thèmes disponibles pour la visualisation dans le système interne de Vim. Autre moyen: exécutez helptags ALL après avoir téléchargé le package, et la commande prendra en charge tous les fichiers et leurs chemins d'exécution.
Lorsque vous souhaitez utiliser un package, téléchargez-le simplement et n'oubliez pas que dans ce cas, la résiliation fonctionne à l'aide d'onglets, vous n'avez donc pas besoin d'entrer le nom complet:

 :packadd ctrlp.vim-1.79

Le répertoire de base de Packadd se trouve dans le runtimepath, ce qui lui permet d'utiliser les scripts de son plugin et ftdetect. Après avoir chargé ctrlp, vous pouvez utiliser la commande CTRL-P pour ouvrir la recherche de fichiers par correspondance partielle.

Certaines personnes gardent une trace de leur répertoire ~ / .vim et utilisent git pour contrôler la version de chaque paquet. Pour ma part, je viens de décompresser les packages des archives tar et de les suivre manuellement via le référentiel. Si vous utilisez des packages suffisamment matures qui ne nécessitent pas de mises à jour fréquentes, ainsi que des scripts, ils sont assez petits et n'encombrent pas l'historique git.

Sauvegardes et restaurations de versions

En fonction de vos préférences utilisateur, Vim peut vous protéger contre quatre causes possibles de perte de données:

Crash lors de l'édition (entre les sauvegardes). Vim peut se protéger contre cela en enregistrant périodiquement les modifications apportées au fichier d'échange.
Protection contre la modification du même fichier avec deux instances Vim, protection contre l'écrasement des modifications apportées via une ou plusieurs instances. Cela se fait également via le fichier d'échange.
Échec lors du processus d'enregistrement lui-même après la modification du fichier final, mais jusqu'à ce que le nouveau contenu soit complètement écrit. Vim peut vous en protéger grâce à la fonction d'écriture différée. Pour ce faire, il crée en cours de sauvegarde un nouveau fichier, qui remplace ensuite l'original, si tout s'est bien passé. La méthode de remplacement est déterminée par le paramètre de copie de sauvegarde.
Sauvegarde du nouveau contenu du fichier à condition que l'original soit restauré. Vim vous permet d'enregistrer une copie de sauvegarde d'un fichier après avoir apporté des modifications.

Mais avant de commencer à explorer ces paramètres intelligents, que diriez-vous de quelques blagues? Voici quelques exemples de commentaires provenant de fichiers vimrc sur GitHub:

«Ne créez pas de fichier d'échange. Gérez tout grâce au contrôle de version. »
«Sauvegardes pour les exilés. Utilisez le contrôle de version. "
"Seul contrôle de version!" Seulement hardcore! ”
"Nous vivons dans un monde de contrôle de version, donc les échanges et les sauvegardes sont à la poubelle."
"Pourquoi avez-vous besoin de fichiers de sauvegarde si le contrôle de version est suffisant."
"Je n'ai jamais utilisé de fichiers de sauvegarde Vim ... Utilisez le contrôle de version."
"La plupart des choses peuvent être trouvées grâce au contrôle de version."
Msgstr "Désactivez les sauvegardes de fichiers, car vous utilisez toujours le système de contrôle de version;)".
"Et le contrôle de version est venu, et Git nous a sauvés."
«Désactiver les fichiers d'échange et le système de sauvegarde. Utilisez toujours le contrôle de version! TOUJOURS! ”
"Je n'ai pas besoin d'une sauvegarde, car je travaille avec le contrôle de version."

L'ironie est que les commentaires ci-dessus ne reflètent qu'une compréhension du quatrième et, en partie, du troisième type d'échec. Si vous refusez le fichier d'échange et la sauvegarde, vous perdrez la protection dans le cas décrit aux paragraphes 1 et 2.

Voici un exemple de configuration que je recommande pour un fonctionnement sûr:

 " Protect changes between writes. Default values of " updatecount (200 keystrokes) and updatetime " (4 seconds) are fine set swapfile set directory^=~/.vim/swap// " protect against crash-during-write set writebackup " but do not persist backup after successful write set nobackup " use rename-and-write-new method whenever safe set backupcopy=auto " patch required to honor double slash at end if has("patch-8.1.0251") " consolidate the writebackups -- not a big " deal either way, since they usually get deleted set backupdir^=~/.vim/backup// end " persist the undo tree for each file set undofile set undodir^=~/.vim/undo//

Ces paramètres incluent des sauvegardes pour les enregistrements incomplets, mais n'enregistrent pas les fichiers une fois l'opération terminée avec succès, car nous avons le contrôle de version, le meilleur contrôle de version, bla bla bla, etc. etc. Veuillez noter que vous pourriez avoir besoin de mkdir ~ / .vim / {swap, undodir, backup}, sinon Vim accèdera au prochain dossier lisible. Vous devrez également probablement exécuter la commande chmod sur les dossiers cibles afin que leur contenu soit privé, car les fichiers d'échange et l'historique de sauvegarde peuvent contenir des informations sensibles.

Il convient de noter que la caractéristique de nos chemins de configuration est qu'ils se ferment toujours avec une barre oblique. Cette orthographe permet à la fonction d'éliminer toute ambiguïté possible dans les chemins des fichiers de pagination et de sauvegarde pour les fichiers portant les mêmes noms, qui se trouvent dans des répertoires différents. Par exemple, le fichier d'échange pour / foo / bar sera enregistré dans ~ / .vim / swap /% foo% bar.swp (j'ai échappé aux barres obliques avec des signes de pourcentage). Il y avait un bogue dans le correctif Vim récent qui empêchait la barre oblique d'être prise en compte pour backupdir, donc la protection contre celle-ci est montrée ci-dessus.

Notre Vim enregistre également l'historique de restauration pour chaque fichier, vous pouvez donc restaurer la version correcte même après avoir quitté le mode d'édition. Bien qu'une telle fonction puisse sembler redondante dans le contexte du fichier d'échange que nous avons déjà, l'historique de restauration est une ligne de défense supplémentaire pendant l'enregistrement du fichier.

Lorsque nous parlons de restauration, il convient de rappeler que Vim prend en charge une arborescence complète de l'historique des modifications de fichiers. Cela signifie que vous pouvez apporter une modification, l'annuler, puis répéter les mêmes modifications à nouveau, et tout cela correspondra à trois points de récupération différents. L'heure et l'étendue des modifications apportées peuvent être vérifiées à l'aide de la commande undolist, mais il est problématique d'en extraire l'arborescence. : 5 , . , — , undotree — .

. . : . , .

: , ,vim . nowritebackup, , . , Vim , . backupskip .

«patchmode» Vim . , . , tar-, , git. set patchmod = .orig foo- foo.orig.

Include path

(include) . Vim path, include, suffixesadd, includeexpr. (. help include-search) — ctags .

. , . , help include .

, [i , , [d . gf Vim . :find, **/* , . , .. , .

, . ( ) CTRL-D. .

 " fuzzy-find lite nmap <Leader><space> :e ./**/

: path (headers) . , : checkpath, , . C checkpath. , , . , checkpath , .

«., / Usr / include ,,» . , — /usr/include, . , :help file-searching .

ftplugin ( ) , . : ./src/include ./include.

 setlocal path=.,,*/include/**3,./*/include/**3 setlocal path+=/usr/include

«**3» — . , . , .

, , :checkpath , . , , .

: :he [, :he gf, :he :find .

Histoire de Vim et un guide pour son utilisation efficace