Table of contents

1. Introduction (vim_lib)
2. Plugin Manager without fatal flaws (vim_lib, vim_plugmanager)
3. Project level and file system (vim_prj, nerdtree)
4. Snippets and File Templates (UltiSnips, vim_template)
5. Compiling and doing anything (vim-quickrun)
6. Work with Git (vim_git)
7. Deploy (vim_deploy)
8. Testing with xUnit (vim_unittest)
9. The library on which everything is kept (vim_lib)
10. Other useful plugins

Projects are something that Vim really misses. The project implementation allows not only to select it as a separate entity from other folders and files in the file system, but also to implement such whistles as:

• Automatically saving and restoring the last session of the project so that after re-opening, we will get the file (s) edited last time, with the same settings and position
• Storing information about a project, such as the author of the project, license, version, and so on. All this data can be added to templates and snippets.
• The root directory of the project is strictly defined. This will simplify the use of other tools, for example xUnit, debuggers, documentation generators, etc.
• A separate, project-only .vim directory and a .vimrc file, similar to user versions. Now the project settings and plugins will be stored in it.

Projects in Vim

I don’t know why, but Vim users either do not use the design model, or implement / use rather strange plugins, which, in fact, provide only a fraction of the necessary project functionality. Vim has ready-made mechanisms for implementing a new project level, this is an exrc option that forces Vim to search and launch a .vimrc file in the root directory when loaded, but obviously this is not enough. What is missing from this solution? First of all, we get one thick .vimrc file in the project, which becomes more difficult to change over time. Secondly, overriding Vim configurations for a project, such as: lights, snippets, templates, plugins - becomes more difficult. Ideally, a project needs both a .vimrc file and its own .vim directory (analog to .idea ). This directory should repeat the functionality of its fellow user-level, which means using the same subdirectories and the same boot logic (if possible, by means of Vim itself, so that everything is transparent and flexible).
')

One small plugin

The connection and use of the .vim directory is implemented by the already familiar library vim_lib . The sys / Autoload class connects the project directory .vim to the runtimepath so that it loads in the correct sequence (last) and can override any Vim settings. The rest of the logic is implemented by the vim_prj plugin. His tasks include:

• Connect using the exrc option .vimrc file
• Save and restore the last session of the project
• Create project infrastructure by team
• Store project options such as author, license, etc.
• Store information about the location of the project in the FS and all levels of loading

Project .vimrc

If anyone does not know, the exrc option causes Vim to search in the current directory (the directory in which the editor is running) files with the names .vimrc or _vimrc and run them. The vim_prj plugin simply sets this option to “on”.

Project Sessions

Everything is not much more complicated here. Vim out of the box can save and restore a session using the file storing information about the session and the mksession command . The sessionoptions option allows you to determine which data will be saved and which you can “forget”.

The plugin responds only to projects (the root directory contains .vim ) and automatically saves and restores the last session when opening and closing a project. The project session is stored in the .vim / session.vim file.

Project infrastructure

In order for the plugin to work with some directory as a project, it is enough to create an .vim directory in it. All lazy programmers in the voice will say - what am I to create with my hands? - of course not! For this, the plugin implements the VimPrjCreate command, which in addition to .vim creates the .vimrc file in the project, initializes it according to the requirements of the sys / Autoload loader, creates the .vim / plugins.vim and .vim / bundle . This structure allows you to quickly install plugins using vim_plugmanager (they are immediately connected to .vim / plugins.vim ).

Project Information

The global dictionary vim_prj # opt created by the plugin is not something special, but simply defines the place where the data about the project should be stored. You can set general information for all projects in your user ~ / .vimrc

and redefine them for a specific project in a project’s .vimrc file.

This dictionary is actively used by my snippets and templates, which allows you to quickly change the information about the project, without digging into a bunch of files.

Project house

A very useful feature of the plug-in, which did not even have to be implemented, is to determine the location of the project in the file system. If you open the Vim editor in the root directory of the project (in which .vim is stored), then you are working in the project, otherwise, you just opened the editor. Accordingly, the plug-in will know the address of the root directory of the project, all other levels of the editor ($ VIMRUNTIME and ~ / .vim ) that other plugins may need. Naturally, in order to work with such a project, you need the ability to view the file structure of the project and open files. This is done using the nerdtree plugin. In other words, you simply open the editor at the root of your project with the vim command, and get all the charms inherent in the project.

Bye all

I see no reason to paint the nerdtree plugin in this article (I think you already know about it), let me just say that in the future it will be replaced or rewritten, since it lacks some of the functions required by the file manager and a convenient API for use by other plugins.