Humane VimScript: Editor-Initialisierung

    Einführung


    Bei jedem Start des Vim-Editors wird ein Initialisierungsprozess ausgeführt, der dem Benutzer eine praktische Oberfläche bietet. Auf den ersten Blick mag das Initialisierungsmodell einfach und verständlich erscheinen, aber dies ist bei weitem nicht der Fall.


    In diesem Artikel empfehle ich Ihnen, sich mit dem Initialisierungsprozess des Vim-Editors vertraut zu machen. Ich halte dieses Thema für eines der schwierigsten während des Studiums des Herausgebers, weshalb das von mir vorgestellte Material sowohl für Anfänger, die diesen heiklen Weg beginnen, als auch für erfahrene Benutzer und Entwickler sehr nützlich sein kann.


    Die Komplexität dieses Themas ist auf das nicht triviale Modell des Ladens von Skripten des Editors sowie auf die Anzahl der Gruppen zurückzuführen, in die diese Skripte unterteilt sind. Es ist ziemlich schwierig, sich an die Initialisierungsreihenfolge des Editors zu erinnern, aber es ist sehr wichtig, eigene Plugins dafür zu schreiben.


    Editor-Initialisierung


    Wer?


    Überlegen Sie zunächst, wer für das Laden der Skripte und deren Initialisierung des Editors verantwortlich ist. In Vim gibt es nur zwei solche Ladepunkte:


    • Editor - Die Logik, die direkt in den Editorcode "eingenäht" wird, ist für das Suchen und Laden von Skripten verantwortlich
    • Skripte - Die Logik anderer Skripte ist für das Suchen und Laden von Skripten verantwortlich

    Schauen Sie sich die Datei an, um es klarer zu machen $VIM/vimrc. Dieses Skript wird von der Logik des Editors selbst geladen (und ausgeführt). Andererseits enthält das Skript selbst $VIM/vimrcin der Regel die Logik zum Laden anderer Skripte.


    Ein wichtiger Unterschied zwischen vom Editor geladenen Skripten und den übrigen Skripten besteht darin, dass erstere nur mithilfe von Vim-Startoptionen deaktiviert (oder verbunden) werden können, z. B. -u(gibt das Root-Benutzerskript an) oder --noplugin(verbietet das Laden von Plugins). Geladene Skripte können wiederum die Initialisierung mithilfe einer vom Entwickler programmierten Logik steuern.


    Wann?


    Zur Vereinfachung und Verbesserung der Sicherheit des Editorinitialisierungsprozesses ist der Mechanismus in zwei Hauptphasen unterteilt:


    • Systemweit - In dieser Phase heruntergeladene Skripte wirken sich auf den Betrieb aller Computerbenutzer aus
    • Zu diesem Zeitpunkt heruntergeladene Benutzerskripte wirken sich nur auf den aktuellen Computerbenutzer aus

    Mit der Option kann eine exrcandere Stufe verbunden werden:


    • In dieser Phase geladene Design-Skripte wirken sich nur auf den Betrieb der aktuellen Editorsitzung aus

    In der Tat können Sie Ihre eigenen Schritte zu den vorhandenen hinzufügen. Es ist nur wichtig, die Ladereihenfolge und den Verantwortungsbereich jeder Stufe zu beachten.


    Die Reihenfolge beim Laden von Skripten ist nicht streng. Dies wird durch den Inhalt der Option bestimmt runtimepath, in der die Adressen der Verzeichnisse aufgelistet sind, in denen die Initialisierungsdateien in der Reihenfolge gespeichert sind, in der sie geladen werden sollen.


    Leider ist dies der unvorhersehbarste Teil des Editor-Initialisierungsmechanismus. Tatsache ist, dass hier die Ladereihenfolge überhaupt nicht verwendet wird, was Ihnen am offensichtlichsten erscheint. Insbesondere ohne ordnungsgemäße Konfiguration wird zuerst die Initialisierung von Benutzerskripten und erst dann systemweit durchgeführt. Dies kann durch einen Blick auf den Inhalt der Optionen zu sehen runtimepathich habe , ist es (ohne Anpassung) runtimepath=~/.vim,/usr/share/vim/vimfiles,/usr/share/vim/vim74,/usr/share/vim/vimfiles/after,~/.vim/after.


    Wie Sie sehen können, sind die ersten in der Initialisierungswarteschlange Benutzerskripte. Dies bedeutet, dass sie beim Starten des Editors systemweit überschrieben werden. Unerwartet, nicht wahr? Ich rätsele immer noch über den Grund, der die Autoren dazu veranlasst hat, eine solche Initialisierungsreihenfolge anzuwenden.


    Was?


    Editor-Initialisierungsskripte werden abhängig von den Zielen wie folgt gruppiert:


    • Base (.vimrc) - Skripte, die für die allgemeine Initialisierung des Editors verantwortlich sind
    • Kontextsensitiv (ftdetect /) - Skripte, die für die Identifizierung des Kontexts verantwortlich sind (z. B. eine bearbeitete Datei)
    • Kontextsensitiv (ftplugin /) - Skripte, die den Editor je nach Kontext initialisieren
    • Farbschemata (Farben /) - Regeln zum Hervorheben der Benutzeroberfläche
    • Compiler-Unterstützungsskripte (compiler /) - Skripte zur Verwendung von Compilern
    • Referenzen (doc /) - Dokumentation
    • Tastaturlayoutdateien (Keymap /) - Zuordnung von Tastaturlayouts
    • Menükonfiguration (menu.vim) - Menükonfigurationsdatei
    • Menüübersetzungen (lang /) - Menülokalisierungsdatei
    • Syntaxhervorhebung (syntax /) - Konfiguration der Sprachsyntaxhervorhebung
    • Plugins (plugin /) - Plugin-Initialisierungsskripte
    • Einrückungsskripte (Einzug /) - Einrückungskonfiguration
    • Unterstützende Skripte zum Drucken (print /) - Drucksystemkonfiguration
    • Tutorial-Dateien (tutor /) - Tutorial-Dateien

    Eine solche Vielzahl von Skripten, die für die Initialisierung verwendet werden, ist auf die Funktionalität des Editors zurückzuführen. Natürlich verbietet niemand die Verwendung eines einzigen Initialisierungsskripts zum Konfigurieren aller Editormechanismen (z. B. in einer Datei ~/.vimrc), aber ich empfehle dies nicht (die Datei schwillt schnell an, wissen Sie).


    Kontextsensitive Skripte


    Der Kontext von Skripten sollte separat besprochen werden. Im Gegensatz zu einigen Editoren ist Vim nicht an eine bestimmte Syntax oder Sprache gebunden. Mit ihm können Sie genauso einfach ein Buch schreiben, den Quellcode eines Programms bearbeiten oder mit binären (Hex-) Dateien arbeiten. Dies wird durch die Möglichkeit erreicht, die Konfiguration mit einem bestimmten Editorpuffer zu lokalisieren. Mit anderen Worten, Sie können ein Editorfenster mit dem ersten Skript und das zweite mit dem zweiten konfigurieren, je nachdem, welche Art von Dateien darin bearbeitet werden. Die Art der Dateien, in diesem Fall nenne ich den Kontext.


    Wie Sie (möglicherweise) wissen, ist Vim abwärtskompatibel mit dem Vi-Editor, der wiederum unter Berücksichtigung der Besonderheiten von Unix-ähnlichen Systemen erstellt wurde. Aus kontextbezogener Sicht bedeutet dies, dass der Typ der bearbeiteten Datei nicht immer durch ihren Namen (Erweiterung) bestimmt werden kann. Oft muss der Editor für diese Zwecke mit dem Inhalt der bearbeiteten Datei arbeiten. Zu diesem Zweck werden kontextsensitive Skripte verwendet, die sich im Verzeichnis befinden ftdetect/, sowie ein Skript filetype.vim.


    Sobald der Kontext definiert ist, werden Verzeichnisskripte für die bearbeitete Datei aufgerufen ftplugin/. Ihre Konfigurationen sollten (ohne darauf beschränkt zu sein) nur für den aktuellen Puffer gelten.


    Konfiguration der Initialisierungs-Engine


    Sie können den Editor-Initialisierungsmechanismus selbst konfigurieren, müssen dies jedoch mit äußerster Vorsicht tun. Ich empfehle nicht, den Inhalt systemweiter Initialisierungsskripte zu ändern, da dies zu unerwartetem Editorverhalten führen kann.


    Bevor Sie mit der Konfiguration des Initialisierungsmechanismus fortfahren, öffnen Sie Ihren Vim-Editor und führen Sie den Befehl :scriptnamesaus. Zu Beginn des Editors wird eine Liste der heruntergeladenen Dateien angezeigt. Dies sind sehr nützliche Informationen, auf die Sie ständig verweisen, um herauszufinden, warum ein bestimmtes Skript nicht mehr funktioniert. Mithilfe dieser Liste ist es auch einfach, die Initialisierungsreihenfolge des Editors zu verfolgen.


    Wie kann der Initialisierungsmechanismus konfiguriert werden? Führen Sie zunächst den Befehl aus set runtimepath?und sehen Sie sich den Inhalt der Option an runtimepath. Sie können die Ladereihenfolge Ihrer Initialisierungsdateien ändern oder neue Verzeichnisse damit bereitstellen. Um dies zu tun, öffnen Sie die Datei ~/.vimrcund fügen Sie den folgenden Eintrag hinzu: set runtimepath=каталоги разделенные запятой. Wenn Sie den Editor neu starten, wird die von Ihnen angegebene Startreihenfolge bereits angewendet. Beachten Sie jedoch ~/.vimrc, dass der Editor bis zum Hochladen Ihrer Datei die in den systemweiten Konfigurationsdateien angegebene Initialisierungsreihenfolge verwendet.


    Eine andere Möglichkeit, den Initialisierungsmechanismus zu konfigurieren, besteht darin, eine zusätzliche Entwurfsinitialisierungsphase anzuschließen. Um dies zu tun, fügen Sie Ihre Datei ~/.vimrcdie folgende Zeile: exrc. Wenn der Editor gestartet wird, wird nicht nur die Benutzerinitialisierungsdatei ausgeführt ~/.vimrc, sondern auch die gleichnamige Datei im aktuellen Verzeichnis ( ./.vimrc). Es kann verwendet werden, um den Editor für jedes spezifische Projekt zu konfigurieren. Darüber hinaus verhindert , dass Sie nichts zu Ihrem Projektverzeichnis hinzufügen .vimund in die Datei schreiben ./.vimrc: set runtimepath+=./.vim. Danach .vimähnelt Ihr Projektverzeichnis dem Benutzerverzeichnis ~/.vim, wodurch die Strukturierung Ihrer Projektkonfigurationsdateien erleichtert wird.


    Tschüss


    Ja, der Artikel ist ziemlich kompliziert, nicht voller Beispiele und wiederholt teilweise die Dokumentation. Tatsache ist, dass dies eine Einführung in ein anderes, interessanteres Thema ist, das ich in Zukunft behandeln werde, aber es wäre zu schwierig, dies ohne dieses Wissen zu tun.


    Jetzt auch beliebt: