Introduction

Each time Vim is run, it runs an initialization process that provides a convenient interface for the user. At first glance, the initialization model may seem simple and understandable, but this is far from the case.

In this article, I suggest that you familiarize yourself with the initialization process of the Vim editor. I consider this topic to be one of the most difficult in the course of studying the editor, from which the material presented by me can be very useful both for beginners starting this thorny path and for experienced users and developers.

The complexity of this topic is due to the nontrivial model of loading scripts of the editor, as well as the number of groups into which these scripts are divided. Remembering the initialization order of the editor is quite difficult, but it is very important for writing your own plugins for it.

Editor initialization

Who!

To begin, consider who is responsible for loading the scripts and, with their help, the initialization of the editor. There are only two such loading points in Vim:

• Editor - for the search and download scripts responsible logic, "sewn" directly into the code editor
• Scripts - the logic of other scripts is responsible for searching and downloading scripts

To make it clearer, take a look at the $VIM/vimrc file. This script is loaded (and executed) by the logic of the editor itself. On the other hand, the $VIM/vimrc script itself, as a rule, includes logic for loading other scripts.

An important difference between the scripts loaded by the editor and the rest is that the first ones can be disabled (or connected) only using Vim startup options, such as -u (indicates the user’s root script) or --noplugin (prohibits the loading of plug-ins). In turn, the loaded scripts can control the initialization with the help of some logic programmed by the developer.

When?

For convenience and to increase the security of the initialization process of the editor, the mechanism is divided into two main stages:

• System-wide - the scripts loaded at this stage affect the operation of all computer users.
• Custom - scripts loaded at this stage affect the operation of only the current computer user.

Using the exrc option, one more step can be connected:

• Project - scripts loaded at this stage affect the work of the current editor session only.

In fact, you can add your own stages to existing ones, it is only important to follow the order of loading and area of ​​responsibility of each stage.

The order of loading scripts is not strict. It is determined by the contents of the runtimepath option, which lists the addresses of directories that store initialization files in the order in which they should be loaded.

Unfortunately, this is the most unpredictable part of the editor initialization mechanism. The fact is that it does not apply the order of loading, which might seem to you the most obvious. In particular, without proper configuration, user scripts will be initialized first, and then system-wide. This can be verified by looking at the contents of the runtimepath option, I have it (without settings): runtimepath=~/.vim,/usr/share/vim/vimfiles,/usr/share/vim/vim74,/usr/share/vim/vimfiles/after,~/.vim/after .

As you can see, user scripts are the first in the initialization queue, which means that they will be redefined system-wide at the start of the editor. Unexpected, isn't it? I am still puzzling over the reason that prompted the authors to apply this order of initialization.

What?

Editor initialization scripts are grouped as follows, depending on the goals:

• Basic (.vimrc) - scripts that are responsible for the overall editor initialization
• Context-defining (ftdetect /) - scripts responsible for identifying the context (such as the file being edited)
• Context-sensitive (ftplugin /) - scripts that initialize the editor depending on the context
• Color schemes (colors /) - interface highlighting rules
• Compiler support scripts (compiler /) - scripts for using compilers
• Directories (doc /) - documentation
• Keyboard layout files (keymap /) - keyboard layout mapping
• Menu configuration (menu.vim) - menu configuration file
• Menu translations (lang /) - menu localization file
• Syntax Highlighting (syntax /) - language syntax highlighting configuration
• Plug-ins (plugin /) - plug-in initialization scripts
• Indenting scripts (indent /) - indent configuration
• Printing support scripts (print /) - printing system configuration
• Tutorial files (tutor /) - tutorial files

Such a variety of scripts used for initialization is due to the functionality of the editor. Of course, no one forbids using a single initialization script to configure all editor mechanisms (for example in the ~/.vimrc file), but I do not recommend it (the file swells quickly, you know).

Context-sensitive scripts

The context of the scripts should be discussed separately. Unlike some editors, Vim is not tied to a specific syntax or language. With it, you can equally easily write a book, edit the source code of the program or work with binary (hex) files. This is achieved due to the possibility to localize the configuration with a specific editor buffer. In other words, you can configure one editor window using the first script, and the second one using the second one, depending on the type of files edited in it. The type of files, in this case, I call the context.

As you may (probably) know, Vim is backward compatible with the Vi editor, which, in turn, was designed to take into account the features of Unix-like systems. From the point of view of context, this means that the type of file being edited cannot always be determined by its name (extension), often for these purposes the editor needs to work with the contents of the file being edited. For these purposes, context-defining scripts are used, which are located in the ftdetect/ directory, as well as the filetype.vim script.

After the context has been defined, the scripts in the ftplugin/ directory are ftplugin/ for the file being edited. Their configurations should (but this is not limited in any way) be applied only to the current buffer.

Configuration initialization mechanism

You can customize the editor's initialization mechanism, but this should be done very carefully. I do not recommend that you change the contents of system-wide initialization scripts, as this may lead to unexpected editor behavior.

Before proceeding with the configuration of the initialization mechanism, open your Vim editor and execute the command :scriptnames , you will see a list of files loaded at the start of the editor. This is very useful information that you will constantly refer to in order to find out why a particular script has stopped working. Also with the help of this list it is easy to follow the order of initialization of the editor.

And so, how can you configure an initialization mechanism? First run the set runtimepath? and take a look at the contents of the runtimepath option. You can change the order of loading your initialization files or add new directories with it. To do this, open the ~/.vimrc file and add the following entry to it: set runtimepath= . When you restart the editor, the boot order you specified will already be applied. Consider only that prior to loading your ~/.vimrc file, the editor will use the order of initialization specified in the system-wide configuration files.

Another way to configure the initialization mechanism is to connect an additional, design initialization stage. To do this, add the following line to your ~/.vimrc file: exrc . Now at the start of the editor, not only the user initialization file ~/.vimrc will be executed, but the file with the same name in the current directory ( ./.vimrc ). It can be used to configure the editor for each specific project. Moreover, nothing prevents you from adding the .vim directory and writing to the ./.vimrc : set runtimepath+=./.vim ./.vimrc file in the project. After that, your .vim project directory will become similar to the user directory ~/.vim , which will facilitate the structuring of your project configuration files.

Bye all

Yes, the article is rather complicated, it is not replete with examples and partially repeats the documentation. The fact is that this is an introduction to another, more interesting topic, which I will try to cover in the future, but it will be too difficult to do this without this knowledge.