Die Geschichte von Vim und eine Anleitung zu seiner effektiven Verwendung

Anmerkung des Übersetzers: Dies ist der erste Teil des monumentalen (tatsächlich monumentalen) Artikels über Vim und seine Fähigkeiten, den der Entwickler aus Minneapolis und der Autor des PostgREST- Projekts , Joe begriffs Nelson, verfasst haben.

Der erste Teil des Artikels befasst sich mit der Geschichte von Vim als Herausgeber und der Autor spricht über eine Reihe interessanter Fakten über die Fähigkeiten von Vim. Im zweiten Teil der Übersetzung konzentrieren sich alle Chips und Life-Hacks, die Joe mit dem Publikum teilen möchte, da die Erzählung als solche verblasst und nur noch eine Reihe von Handlungsrichtlinien vorhanden sind. Da der Originaltext völlig inakzeptable Dimensionen aufweist, haben wir diese Geschichte in zwei ungefähr gleich große Artikel unterteilt. Heute ist die erste von zwei Veröffentlichungen. Viel Spaß beim Lesen.



Dieser Artikel basiert auf der Erforschung der Geschichte von Vim und dem durchgängigen Lesen des Benutzerhandbuchs. Ich hoffe, diese Notizen helfen Ihnen dabei, die grundlegenden Funktionen dieses Editors für sich selbst zu entdecken (oder wiederzuentdecken?) Und ermöglichen es Ihnen, die Verwendung von vimrc-Dateien mit Warnhinweisen aufzugeben und Plug-ins durchdachter zu verwenden.



Referenzliste


Um über die üblichen Themen hinauszugehen, würde ich empfehlen, eine gedruckte Version dieses Handbuchs und eine umfangreiche Taschenreferenz mitzunehmen. Ich konnte kein gedrucktes Exemplar des Benutzerhandbuchs für Vim finden. Am Ende habe ich nur die PDF-Datei gedruckt, die mit dem Editor über printme1.com geliefert wurde. $VIMRUNTIME/doc/usr_?? es mit Software in $VIMRUNTIME/doc/usr_?? . Als bequeme Liste von Befehlen kann ich das Nachschlagewerk "Vi and Vim Editors Pocket" empfehlen.

Inhalt

  • Die Geschichte
  • Konfigurationshierarchie
  • Plugins von Drittanbietern
  • Backups und Kickbacks
  • Include und Pfad
  • Bearbeiten und Kompilieren einer Schleife
  • Diffs und Patches
  • Ein- / Ausgabepuffer
  • Dateitypen
  • Vergiss die Maus nicht
  • Verschiedenes

Die Geschichte


Geburt vi


Vi-Befehle und -Funktionen gibt es seit mehr als fünfzig Jahren, angefangen mit dem QED-Editor. Hier ist seine Timeline:

  • 1966: QED (Quick Editor) am Berkeley Timesharing System
  • Juli 1969: Mit seiner Hilfe landeten sie auf dem Mond (na ja, als Referenz)
  • Aug 1969: QED → Hrsg. Bei AT & T
  • 1976 Feb: ed → em („Herausgeber für Sterbliche“) am Queen Mary's College
  • 1976: em → ex ("EXtended") an der University of California, Berkeley
  • 1977 Okt: Ex empfängt visuellen Modus, Vi - Text - Terminal

Wenn Sie das QED- und das Ex- Handbuch lesen, werden Sie möglicherweise Ähnlichkeiten zwischen ihnen feststellen. Beide Editoren verwenden eine ähnliche Grammatik, um Zeilenbereiche anzugeben und mit diesen zu arbeiten.

Editoren wie QED ed und em wurden für Druckterminals entwickelt, bei denen es sich größtenteils um normale elektrische Schreibmaschinen handelte, an die ein Modem angeschlossen war. Solche "Vollkopierer" -Terminals zeigten Befehle auf Papier an und offensichtlich war es nach der Eingabe unmöglich, irgendwelche Korrekturen vorzunehmen. Daher bestand der Bearbeitungsprozess darin, Benutzerbefehle manuell auf Papier zu bearbeiten und sie dann erneut einzugeben.

1976 erschienen Videoterminals, zum Beispiel ADM-3A. Dem Ex-Editor wurde ein „Öffnungsmodus“ hinzugefügt, der das Bearbeiten über ein Videoterminal auf einer einzelnen Seite ermöglicht. Ein visueller Modus wurde hinzugefügt, um sich mit dem Cursor an den Linien des Terminals zu orientieren. Der visuelle Modus wurde mit dem Befehl „vi“ aktiviert und die auf dem Bildschirm angezeigte Datei ständig aktualisiert, wobei die Position der Befehlszeile am unteren Bildschirmrand beibehalten wurde. Interessante Tatsache: Auf dem ADM-3A wurden Pfeile auf die Tasten h, j, k, l gesetzt, mit denen wir den Cursor auf vi bewegen konnten.

In einem Interview mit Bill Joy erfahren Sie mehr über diesen Übergang von ed zu ex / vi. Darin spricht er darüber, wie er Ex / Vi geschaffen hat und über einige Dinge, die ihn letztendlich enttäuscht haben.

Classic vi ist nur ein alter is ex. Beide werden durch dieselbe Binärdatei dargestellt, die abhängig vom Namen der ausführbaren Datei sowohl im Ex-Modus als auch im Vi-Modus ausgeführt werden kann. Das Erbe dieser ganzen Geschichte ist, dass ex / vi sich bei Verwendung „entfaltet“, fast keine Systemressourcen benötigt und unter Bedingungen mit begrenzter Bandbreite arbeiten kann. Es ist auch auf den meisten vorhandenen Systemen verfügbar und wird in POSIX vollständig beschrieben .

Vi zu vim


Der von ed abgeleitete Ex / Vi-Editor war geistiges Eigentum von AT & T. Um vi auf anderen Plattformen als Unix zu verwenden, mussten Benutzer Klone schreiben, die eine andere Quellcodebasis hatten.

Hier sind einige von ihnen:

  • nvi - 1980 für 4BSD
  • calvin - 1987 für DOS
  • vile - 1990 für DOS
  • Stevie - 1987 für Atari ST
  • elvis - 1990 für Minix und 386BSD
  • vim - 1991 für Amiga
  • Viper - 1995 für Emacs
  • elwin - 1995 für Windows
  • lemmy - 2002 für Windows

Wir werden uns auf den Klon aus der Mitte der Liste konzentrieren - Vim. Bram Mulenaar wollte vi auf Amiga verwenden und begann mit Atari zu portieren und den vi-Klon Stevie zu entwickeln. Und er nannte seine Version des Hafens "Vi Imitation". Wenn Sie diesen Prozess aus erster Hand kennenlernen möchten, sehen Sie sich sein Interview für das Free Software Magazine an.

In Version 1.22 wurde Vim in "Vi IMproved" umbenannt, was auf die Überlegenheit der Kopie gegenüber dem Original hinweist. Hier ist ein Diagramm der folgenden Hauptversionen mit Beschreibungen einiger Funktionen:



Für weitere Informationen zu jeder Version sollte die Hilfe verwendet werden, z. B. für vim8. Um die geplanten Updates sowie eine Liste der bekannten Fehler anzuzeigen, sollten Sie sich an todo.txt wenden.

Beispielsweise enthielt die achte Version eine gewisse Unterstützung für asynchrone Jobs, da das Projekt von NeoVim unter Druck gesetzt wurde. Die Entwickler der letzteren wollten Debugging und REPL für Web-Skripte direkt im Editor ausführen.

Generell ist Vim superportabel. Dieser Editor passte die gesamte Geschichte seines Bestehens an die Arbeit auf völlig anderen Plattformen an und war gezwungen, im Rahmen der „einfachen“ Kultur des Codierens zu bleiben. Vim läuft unter OS / 390, Amiga, BeOS und BeBox, Macintosh Classic, Atari MiNT, MS-DOS, OS / 2, QNX, RISC-OS, BSD, Linux, OS X, VMS und MS-Windows. Sie können sich überall auf Vim verlassen und es ist Ihnen egal, welche Ausrüstung Sie verwenden.

Am Ende des ursprünglichen vi-Pfades wurde der ex / vi-Quellcode im Jahr 2002 noch unter der BSD-Lizenz für freie Software veröffentlicht. Zauberer sind unter ex-vi.sourceforge.net verfügbar.

Aber lasst uns zur Sache kommen. Bevor Sie mit der Analyse von Vim beginnen, sollten Sie wissen, wie die Konfigurationsdateien organisiert und gelesen werden.

Konfigurationshierarchie


Bisher habe ich fälschlicherweise geglaubt, dass Vim alle Einstellungen und Skripte nur aus der .vimrc-Datei bezieht. Das Betrachten von Repositories mit zufälligen „Punktedateien“ kann diese Meinung nur stärken. Sehr oft laden Leute monströse einzelne .vimrc-Dateien hoch, deren Aufgabe es ist, jeden Aspekt des Editors zu kontrollieren. Diese riesigen Konfigurationen werden manchmal auch "vim distros" genannt.

Tatsächlich hat Vim eine übersichtliche Struktur, in der .vimrc nur einer von vielen „Einstiegspunkten“ ist. Tatsächlich können Sie Vim selbst fragen, welche Skripte geladen werden. Bearbeiten Sie dazu einen Quellcode für ein zufälliges Projekt auf Ihrem Computer, laden Sie ihn herunter und führen Sie den Befehl aus

 :scriptnames 

Diese Liste ist lesenswert. Versuchen Sie zu erraten, was diese Skripte bewirken, und notieren Sie sich die Verzeichnisse, in denen sie sich befinden.

Die Liste war länger als erwartet? Wenn Sie viele Plugins installiert haben, hat der Editor viel zu tun. Stellen Sie sicher, dass es beim Start langsamer wird, indem Sie den folgenden Befehl zum Erstellen von start.log ausführen:

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

Vergleichen Sie einfach, wie schnell Vim von Anfang an startet:

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

Um zu bestimmen, welche Skripte beim Start oder beim Laden des Puffers geladen werden sollen, müssen Sie den Vim-Laufzeitpfad überprüfen. Dieser Pfad wird durch eine durch Kommas getrennte Liste von Verzeichnissen dargestellt, von denen jedes eine gemeinsame Struktur enthält. Vim überprüft diese Strukturen in jedem Verzeichnis, um die Startskripte zu finden. Verzeichnisse werden streng in der Reihenfolge verarbeitet, in der sie sich in der Liste befinden.

Überprüfen Sie den Ausführungspfad auf Ihrem System mit folgendem Befehl:

 :set runtimepath 

Mein System enthält die folgenden Verzeichnisse, die standardmäßig für die Laufzeitpfadüberprüfung angegeben sind. Nicht alle existieren sogar, aber Vim wird immer noch versuchen, auf sie zuzugreifen und den Inhalt zu überprüfen, wenn sie noch vorhanden sind:

~/.vim
Basisverzeichnis für erstellte Profile.

/usr/local/share/vim/vimfiles
Systemweites Vim-Verzeichnis für Profile mit Systemadministratorrechten.

/usr/local/share/vim/vim81
Aka $ VIMRUNTIME, für mit Vim verteilte Dateien.

/usr/local/share/vim/vimfiles/after
Im systemweiten Vim-Verzeichnis befindet sich auch das After-Verzeichnis. Es ist beabsichtigt, die persönlichen Einstellungen des "Standard" -Systemadministrators hinzuzufügen.

~/.vim/after
Das After-Verzeichnis im Home-Verzeichnis. Dies ist erforderlich, damit persönliche Konfigurationen nicht abgebrochen werden oder sich mit den systemweiten oder „Standard“ -Einstellungen überschneiden.

Im Allgemeinen werden Verzeichnisse in derselben Reihenfolge verarbeitet, in der sie in start.log geschrieben sind. Eine Ausnahme gilt nur für "after". Dieser steht immer am Ende der Liste und wird zuletzt abgearbeitet.

Bei der Verarbeitung jedes Verzeichnisses sucht Vim in diesen nach Unterordnern mit bestimmten Namen. Weitere Informationen hierzu finden Sie unter help runtimepath. Hier ist eine kurze Beschreibung derer, die wir im Text weiter betrachten werden:

plugin /
Hier liegen die Vim-Skriptdateien, die beim Bearbeiten eines beliebigen Dateityps automatisch geladen werden. Sie werden auch "global" genannt.

autoload /
(Nicht zu verwechseln mit "Plugin"). Diese Startskripte enthalten Funktionen, die nur auf Anforderung anderer Skripte eingeschränkt werden.

ftdetect /
Skripte zur Bestimmung der Dateitypen. Bei ihrer Arbeit verlassen sie sich auf die Erweiterung, den Speicherort oder den internen Inhalt der Datei.

ftplugin /
Skripte, die beim Bearbeiten von Dateien eines bekannten Typs ausgeführt werden.

compiler /
Legt fest, wie verschiedene Compiler oder Flusenprüfungen ausgeführt und deren Ausgabe analysiert werden. Es kann auf mehrere ftplugins gleichzeitig aufgeteilt werden. Der Compiler wird nicht automatisch ausgeführt und muss von einem Befehl aufgerufen werden.

pack /
Ein Container für native Vim 8-Pakete, der Nachfolger der Paketverwaltung im Pathogen-Stil. Es verfügt über ein eigenes Verpackungssystem und erfordert keinen Code von Drittanbietern.

Und schließlich ist ~ / .vimrc eine Falle für allgemeine ~ / .vimrc . Dient zum Konfigurieren der Standardeinstellungen, die einem bestimmten Dateityp zugewiesen werden können. Um die gesamte Liste anzuzeigen, können Sie .vimrc auswählen und den Befehl options ausführen.

Plugins von Drittanbietern


Plugins sind nur Vim-Skripte, für die es ausreicht, sie an den richtigen Stellen im Laufzeitpfad zu platzieren. Im Allgemeinen ist der Installationsprozess äußerst einfach: Laden Sie einfach die Datei (en) hoch. Das Problem ist, dass einige Plugins sehr schwer zu aktualisieren oder zu entfernen sind, da sie in verschiedenen Unterverzeichnissen verstreut sind und die Ausführungspfade mit ihren Skripten verstopfen. Das heißt, am Ende ist es schwierig zu bestimmen, welche Datei zu welchem ​​Plugin gehört.

Um dieses Problem zu lösen, begannen sich Plugin-Manager zu entwickeln. Auf vim.org gab es mindestens bis einschließlich 2003 eine Plugin-Registrierung (sofern das Archiv nicht lügt). „Plug-in-Manager“ als Einheit sind jedoch erst 2008 in Mode gekommen.

Diese Tools fügen spezielle Verzeichnisse für Plugins hinzu, um Ausführungspfade zu verfolgen und Tags anzuordnen, mit denen Plugins verfolgt werden können. Die meisten Manager rufen auch Plug-in-Updates aus dem Netzwerk auf.

Im Folgenden habe ich Plugin-Manager entsprechend der Chronologie ihres Auftretens erstellt. Basierend auf den Bereichen der Veröffentlichungstermine der ersten und neuesten Versionen. Wenn es keine offiziellen Veröffentlichungen gab, habe ich die frühesten Veröffentlichungstermine und das letzte Update zugrunde gelegt.

  • März 2006 - Juli 2014: Vimball
  • Okt 2008 - Dez 2015: Krankheitserreger
  • Aug 2009 - Dez 2009: Vimana
  • Dez 2009 - Dez 2014: VAM
  • Aug 2010 - Nov 2010: Ruck
  • Okt 2010 - Nov 2012: tplugin
  • Okt 2010 - Feb 2014: Vundle
  • März 2012 - März 2018: Vim-Geschmack
  • April 2012 - März 2016: NeoBundle
  • Jan 2013 - Aug 2017: infizieren
  • Februar 2013 - August 2016: Vimogen
  • Okt 2013 - Jan 2015: Vim-Unbundle
  • Dez 2013 - Jul 2015: Zauberei
  • Februar 2014 - Oktober 2018: Vim-Plug
  • Jan 2015 - Okt 2015: Enabler
  • August 2015 - April 2016: Zauberei 2
  • Jan 2016 - Jun 2018: dein.vim
  • Sep 2016 - Heute: native in Vim 8
  • Februar 2017 - September 2018: Minpac
  • März 2018 - März 2018: autopac
  • Februar 2017 - Juni 2018: Packung
  • März 2017 - September 2017: vim-pck
  • Sep 2017 - Sep 2017: vim8-pack
  • September 2017 - Mai 2019: Volt
  • Sep 2018 - Feb 2019: vim-packager
  • Feb 2019 - Feb 2019: plugpac.vim

Das Erste, worauf Sie in der obigen Liste achten müssen, ist die große Vielfalt. Das zweite - jedes der vorgestellten Werkzeuge „lebt“ seit ungefähr vier Jahren und ist dann höchstwahrscheinlich aus der Mode gekommen.

Der Weg des geringsten Widerstands bei der Plug-in-Verwaltung besteht einfach in der Verwendung der integrierten Vim 8-Funktionalität, für die kein Code von Drittanbietern abgerufen werden muss. Schauen wir uns an, wie es geht.

Erstellen Sie zunächst zwei Verzeichnisse in Ihrem Laufzeitpfad: opt und start.

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

Achten Sie auf den Platzhalter "foobar" (der Name kann geändert werden). Es klassifiziert alle Pakete, die ins Innere gelangen, vollständig. Die meisten Benutzer speichern einfach alle Plugins in einer Kategorie, und dies ist im Allgemeinen normal. Wählen Sie einen beliebigen Namen. Ich werde weiterhin foobar verwenden. Theoretisch können Sie auch mehrere Kategorien erstellen, z. B. ~/.vim/pack/navigation und ~/.vim/pack/linting . Bitte beachten Sie, dass Vim keine Duplikate zwischen Kategorien erkennt und Duplikate, falls vorhanden, zweimal herunterlädt.

Pakete in "start" werden automatisch geladen, während Pakete in "opt" erst von Vim geladen werden, wenn Sie den folgenden Befehl verwenden :packadd . Diese Option eignet sich für selten verwendete Pakete und wird von Vim standardmäßig unterstützt, ohne dass Skripts ausgeführt werden müssen. Beachten Sie, dass :packadd kein Gegenstück zum Entladen von Paketen hat.

Um dieses Beispiel zu überprüfen, fügen wir das CTRLP-Plugin für die Fuzzy-Suche hinzu. Laden Sie die neueste Version herunter und entpacken Sie sie unter:

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

Dieser Befehl erstellt den ~ / .vim / pack / foobar / opt / ctrlp.vim-1.79 fertige Paket ~ / .vim / pack / foobar / opt / ctrlp.vim-1.79 . Kehren Sie zu vim zurück und erstellen Sie die Hilfe-Tag-Zeiger (Helptags-Index) für das neue Paket:

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

Mit diesem Befehl wird eine Datei mit dem Namen "tags" im Ordner mit den Sorten des Pakets erstellt, die Themen zur Anzeige im internen System von Vim zur Verfügung stellt. Alternative Methode: Führen Sie helptags ALL nach dem Herunterladen des Pakets aus, und der Befehl kümmert sich um alle Dateien und ihre Ausführungspfade.
Wenn Sie ein Paket verwenden möchten, laden Sie es einfach herunter und denken Sie daran, dass in diesem Fall die Terminierung mithilfe von Registerkarten funktioniert, sodass Sie nicht den vollständigen Namen eingeben müssen:

 :packadd ctrlp.vim-1.79 

Das Basisverzeichnis von Packadd befindet sich in runtimepath, wodurch Skripte aus seinem Plugin und ftdetect verwendet werden können. Nach dem Laden von ctrlp können Sie den Befehl CTRL-P verwenden, um die Dateisuche nach teilweiser Übereinstimmung zu öffnen.

Einige Leute verfolgen ihr ~ / .vim-Verzeichnis und verwenden git, um die Version jedes Pakets zu kontrollieren. Ich für meinen Teil entpacke einfach Pakete aus Tar-Archiven und verfolge sie manuell durch das Repository. Wenn Sie ausreichend ausgereifte Pakete verwenden, für die keine häufigen Aktualisierungen erforderlich sind, sowie Skripte, sind diese recht klein und verstopfen den Git-Verlauf nicht.

Backups und Rollbacks von Versionen


Abhängig von Ihren Benutzereinstellungen kann Vim Sie vor vier möglichen Ursachen für Datenverlust schützen:

  1. Absturz während der Bearbeitung (zwischen den Speichervorgängen). Vim kann sich dagegen schützen, indem Änderungen an der Auslagerungsdatei regelmäßig gespeichert werden.
  2. Schutz vor dem Bearbeiten derselben Datei mit zwei Vim-Instanzen und vor dem Überschreiben von Änderungen, die über eine oder mehrere Instanzen vorgenommen wurden. Dies geschieht auch über die Auslagerungsdatei.
  3. Fehler während des Speichervorgangs selbst nach dem Ändern der endgültigen Datei, aber bis der neue Inhalt vollständig geschrieben ist. Vim kann Sie mit der Writebackup-Funktion davor schützen. Dazu erstellt er beim Speichern eine neue Datei, die anschließend das Original ersetzt, wenn alles reibungslos lief. Die Ersetzungsmethode wird durch die Einstellung für die Sicherungskopie bestimmt.
  4. Speichern Sie den neuen Inhalt der Datei, sofern das Original wiederhergestellt ist. Mit Vim können Sie eine Sicherungskopie einer Datei speichern, nachdem Sie Änderungen vorgenommen haben.

Aber bevor Sie anfangen, diese intelligenten Einstellungen zu erkunden, wie wäre es mit ein paar Witzen? Hier sind einige Beispielkommentare von vimrc-Dateien auf GitHub:

„Erstellen Sie keine Auslagerungsdatei. Verwalten Sie alles über die Versionskontrolle. “
„Backups für Exilanten. Verwenden Sie die Versionskontrolle. “
"Nur Versionskontrolle!" Nur Hardcore! "
"Wir leben in einer Welt der Versionskontrolle. Auslagerungen und Backups sind also im Papierkorb."
"Warum brauchen Sie Sicherungsdateien, wenn die Versionskontrolle ausreicht?"
"Ich habe noch nie Vim-Sicherungsdateien verwendet ... Versionskontrolle verwenden."
"Die meisten Dinge können über die Versionskontrolle gefunden werden."
Msgstr "Dateisicherungen deaktivieren, da Sie immer noch das Versionskontrollsystem verwenden;)".
"Und die Versionskontrolle kam und Git hat uns gerettet."
Deaktivieren Sie Swap-Dateien und Backup-System. Verwenden Sie immer die Versionskontrolle! IMMER! "
"Ich benötige kein Backup, da ich mit der Versionskontrolle arbeite."

Die Ironie ist, dass die obigen Kommentare nur ein Verständnis der vierten und teilweise dritten Art des Scheiterns widerspiegeln. Wenn Sie die Auslagerungsdatei und die Sicherung ablehnen, verlieren Sie den Schutz in dem in den Absätzen 1 und 2 beschriebenen Fall.

Hier ist eine Beispielkonfiguration, die ich für einen sicheren Betrieb empfehle:

 " 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// 

Diese Einstellungen umfassen Sicherungen für unvollständige Aufzeichnungen, speichern jedoch keine Dateien, nachdem der Vorgang erfolgreich abgeschlossen wurde, da wir die Versionskontrolle, die beste Versionskontrolle, bla bla bla usw. haben. usw. Bitte beachten Sie, dass Sie möglicherweise mkdir ~ / .vim / {swap, undodir, backup} benötigen, andernfalls greift Vim auf den nächsten lesbaren Ordner zu. Sie müssen wahrscheinlich auch den Befehl chmod für die Zielordner ausführen, damit deren Inhalt privat ist, da die Auslagerungsdateien und der Sicherungsverlauf möglicherweise vertrauliche Informationen enthalten.

Es ist erwähnenswert, dass das Merkmal unserer Konfigurationspfade ist, dass sie immer mit einem Schrägstrich schließen. Diese Schreibweise ermöglicht es der Funktion, die mögliche Mehrdeutigkeit in den Pfaden der Auslagerungs- und Sicherungsdateien für Dateien mit demselben Namen, die sich in verschiedenen Verzeichnissen befinden, zu beseitigen. Beispielsweise wird die Auslagerungsdatei für / foo / bar in ~ / .vim / swap /% foo% bar.swp gespeichert (ich habe Schrägstriche mit Prozentzeichen ausgeblendet). In dem kürzlich veröffentlichten Vim-Patch gab es einen Fehler, der verhinderte, dass der Schrägstrich für backupdir berücksichtigt wurde. Der Schutz dagegen ist oben dargestellt.

Unser Vim speichert auch den Rollback-Verlauf für jede Datei, sodass Sie auch nach dem Verlassen des Bearbeitungsmodus die richtige Version wiederherstellen können. Obwohl eine solche Funktion vor dem Hintergrund der bereits vorhandenen Auslagerungsdatei redundant zu sein scheint, ist der Rollback-Verlauf eine zusätzliche Verteidigungslinie bei der Dateiaufzeichnung.

Wenn wir über Rollbacks sprechen, ist zu beachten, dass Vim einen vollständigen Baum der Dateibearbeitungshistorie unterstützt. Dies bedeutet, dass Sie eine Änderung vornehmen, einen Rollback durchführen und dieselben Änderungen dann erneut wiederholen können. Dies sind dann drei verschiedene Wiederherstellungspunkte. Der Zeitpunkt und das Ausmaß der vorgenommenen Änderungen können mit dem Befehl undolist überprüft werden. Es ist jedoch problematisch, den Baum daraus zu entfernen. : 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 .



.

Source: https://habr.com/ru/post/de477768/


All Articles