About Vim “Files and plugins


We need to talk a little about the way configurations are placed. There are two radically different approaches to the way Vim configuration files are placed. Some carefully split the configuration into several files and put them in different places, leaving them in the main file .vimrc only calls :source. This is what a good programmer would do. Others don’t consider Vim configuration to be such a big deal and advise you to put everything in a heap, dividing the settings into only some logical sections. The general opinion is not to stuff the configuration completely randomly.

I probably would have done the first way initially and decomposed everything into some kind of “modules”, but with Vim it’s not so simple. The fact is that various extensions are loaded into the editor sequentially and, moreover, often interact with each other – they depend on each other. That is, to come up with a way to organize files, when in one place we have only hot keys, in another color scheme, by and large, it is impossible. Each plugin separately will have its own hotkeys, perhaps some fine color settings, integration with other plugins.

In addition, Vim has a built-in plugin that loads additional configurations depending on the file type (ftplugin). Which makes the picture even more unobvious. In other words, splitting the configuration into separate files is a big risk, on the contrary, only to confuse yourself. So I propose another compromise.

To main file .vimrc I put only what will work in almost any case in any environment. And finally uploaded ~/.vim/plugins.vim in which everything related to extensions. That is, everything in the directory .vim can be safely disabled at any time. Inside, I tried as much as possible to divide the file into sections with comments on which you can then find the plugin of interest or its specific settings.

Accordingly, in native additional configuration files in directories autoload ftplugin, after, spell I will try my best to avoid situations where they affect the global settings. For example, command declarations would be like at the end of the main .vimrc and in all other files according to the context.


To manage plugins I use vim plug, which, it seems to me, is enough for the eyes. This is the only plugin that needs to be installed manually.

$ curl -fLo ~/.vim/autoload/plug.vim --create-dirs \

Downloading manually and keeping track of all the plugins is also not difficult, but still it is impractical here.

So plugins. First, I would like to dwell again on a kind of gentleman’s set of a programmer without specifics. These are the plugins that, as it seemed to me, firstly, do not greatly duplicate or replace the built-in functionality, do not go beyond the “ideology”, and secondly, they significantly affect performance, but also do not give an addictive effect. Due to the absence of which, you don’t get lost much by running bare Vim. Maybe this is what you should start to get acquainted with initially. But personally, I went a little way back. At first I looked at completely ready-made solutions. Then, I didn’t really like it, and I turned off plugins that I didn’t understand yet. I didn’t like this again and I decided to study the functionality available without the use of plugins, already weaning from the learned ways of working. And now I’m trying to realize whether any extensions and hotkeys are needed in principle, or whether Vim’s built-in capabilities are enough.

The main settings have already been indicated in the previous articles of the series (one, two, three). There I added a few more lines, but about them separately.

The main dish on today’s menu .vim/plugins.vim (https://github.com/johnrembo/provim)

" Plugin section

call plug#begin()

" import .env file
Plug 'tpope/vim-dotenv'

" import .editorconfig file
Plug 'editorconfig/editorconfig-vim'

" fast motions using f F like behavior
Plug 'easymotion/vim-easymotion'

" tag outline 'preservim/tagbar'
Plug 'majutsushi/tagbar', { 'on': 'TagbarToggle' }

" hotkey helper
Plug 'liuchengxu/vim-which-key'

" enable fuzzy finder
Plug 'junegunn/fzf', { 'do': { -> fzf#install() } }
Plug 'junegunn/fzf.vim'

" find project root
Plug 'dbakker/vim-projectroot'

" comment/uncomment blocks and selections
Plug 'preservim/nerdcommenter'

" more informative status bar
Plug 'vim-airline/vim-airline'
Plug 'vim-airline/vim-airline-themes'

" sonokai full color scheme
Plug 'sainnhe/sonokai'

call plug#end()

The first line is the call to vim-plug, which executes the command plug#begin() from a file .vim/autoload/plug.vim.

Further, plugins are connected one by one, and in the specified sequence, which is sometimes important.


The simplest plugin that allows you to import variables and their values ​​from a file .env located on the same path as the opened buffer. Useful for some plugins that can then use them for initialization.


Import generic editor settings http://editorconfig.org/: indentation, end-of-line characters, encoding, and so on. Sets individual editor settings for a project or directory. In at least one project, I had to see such a setting, and I must say, it turned out to be convenient, since the automatic formatting settings were set on the project as the author intended them.


I mentioned this plugin earlier: it should be needed to quickly move around the document. Still can’t figure out how to use it when moving inside long lines, but I’m guessing it’s practically indispensable for this kind of scenario. Still f and F they don’t give such scope, although learning to use them without hesitation is also, I think, a good skill.


Tags are one of the universal concepts for everything related to source code. The plugin with the speaking name simply displays these same tags on the side as a list in a separate window, allowing you to navigate through them. There is something similar in any modern IDE. However, if in the IDE such a panel is often called “outline” and is specific to the programming language, then tags are used here universal. Versatility can be a bit limiting when it comes to professional development, but on average the standard engine is sufficient. If you really need very specific and more accurate code navigators, then they can usually be installed additionally.

To create the appropriate file for the project tree, I use the following command.

command! MakeTags !git ls-files | ctags --links=no -L -

It allows you to mark up only files that are relevant to the project and skip symbolic links. If you need to mark all files forcibly, then you can get by with calling the console command :!ctags -R .. You can also create tags when opening or even saving files, but somehow it didn’t get to that – it’s easier to call it manually when it makes sense to update the list.


I already spoke about this plugin separately in one of the previous articles. For today’s release, I’ve spruced it up a bit and added names for some of the hotkeys in the config. I can additionally note that this is one of those examples when the plugin settings should not be separated into a separate file or even into a separate section. It is better to create labels where these hotkeys actually appear. The separation of defining and setting labels will soon lead to discrepancy, and then to a complete mess.

Somewhere in one place you can group universal labels and initialization

" whichkey

let g:which_key_map = {}
let g:which_key_map['w'] = {
      \ 'name' : '+windows' ,
      \ 'w' : ['<C-W>w'     , 'other-window']          ,
      \ 'd' : ['<C-W>c'     , 'delete-window']         ,
      \ '-' : ['<C-W>s'     , 'split-window-below']    ,
      \ '|' : ['<C-W>v'     , 'split-window-right']    ,
      \ '2' : ['<C-W>v'     , 'layout-double-columns'] ,
      \ 'h' : ['<C-W>h'     , 'window-left']           ,
      \ 'j' : ['<C-W>j'     , 'window-below']          ,
      \ 'l' : ['<C-W>l'     , 'window-right']          ,
      \ 'k' : ['<C-W>k'     , 'window-up']             ,
      \ 'H' : ['<C-W>5<'    , 'expand-window-left']    ,
      \ 'J' : [':resize +5'  , 'expand-window-below']   ,
      \ 'L' : ['<C-W>5>'    , 'expand-window-right']   ,
      \ 'K' : [':resize -5'  , 'expand-window-up']      ,
      \ '=' : ['<C-W>='     , 'balance-window']        ,
      \ 's' : ['<C-W>s'     , 'split-window-below']    ,
      \ 'v' : ['<C-W>v'     , 'split-window-below']    ,
      \ '?' : ['Windows'    , 'fzf-window']            ,
      \ }
let g:which_key_map.b = { 'name' : '+buffers' }
let g:which_key_map.c = { 'name' : '+comment' }
let g:which_key_map.f = { 'name' : '+fzf' }
let g:which_key_map.t = { 'name' : '+tabs tags term' }
let g:which_key_map_visual = {}

nnoremap <silent> <leader> :<c-u>WhichKey '<Space>'<CR>
vnoremap <silent> <leader> :<c-u>WhichKeyVisual '<Space>'<CR>

call which_key#register('<Space>', "g:which_key_map", 'n')
call which_key#register('<Space>', "g:which_key_map_visual", 'v')

and labels for specific combinations will be scattered throughout the configuration.

" tagbar toggle
nmap <leader>tt :TagbarToggle<CR>
let g:which_key_map.t.t="Toggle Tagbar"


Another plugin that relies on an external program is fzf. Whether this program as a whole is needed in the system is a rhetorical question. I still feel purple. But this is one of such programs, after the use of which a sacramental question arises: “Why was it possible?”. And the natural desire was to build its functionality into the editor. Built in. It turned out great, in my opinion.

A small effect of addiction in this case, I think is largely justified. Moreover, Vim itself thanks to set path+=** allows you to perform a similar trick with paths. And when it works not only with files, but also with buffers and registers, then life becomes a little easier.

" fuzzy finder
nmap <leader><tab> <plug>(fzf-maps-n)
xmap <leader><tab> <plug>(fzf-maps-x)
omap <leader><tab> <plug>(fzf-maps-o)

imap <c-x><c-k> <plug>(fzf-complete-word)
imap <c-x><c-f> <plug>(fzf-complete-path)
imap <c-x><c-l> <plug>(fzf-complete-line)

nmap <leader>ff :Files<CR>
nmap <leader>fg :GFiles<CR>
nmap <leader>fb :Buffers<CR>
nmap <leader>fc :Rg<CR>
nmap <leader>fk :Maps<CR>
let g:which_key_map.f.f="FZF files"
let g:which_key_map.f.g = 'FZF Git files '
let g:which_key_map.f.b = 'FZF buffers'
let g:which_key_map.f.c="FZF lines"
let g:which_key_map.f.k = 'FZF keymaps'


All of the above works more naturally when Vim knows where the root of the project is and knows how to jump to the correct directory. Again, you can do such manipulations hand-to-hand, but when you have more than a couple of projects, then soon installation in the correct directory starts to get a little annoying. This plugin does nothing supernatural – it looks for a directory in the parent directories .git or any other names specified in the variable (let g:rootmarkers = ['.svn', '.git']), and sets the working directory there (:cd projectroot#guess()).


Well, what is a programmer without block commenting. Vim’s built-in tools allow you to insert comments in front of a block or frame a selection with comment characters in various ways, but this is done, to put it mildly, not very intuitively. In any case, not quite the way most other editors suggest doing it.

" nerd commenter
map <leader>/ <Plug>NERDCommenterToggle

coloring pages

Below are plugins that are not the most functional at first glance, but also significantly affect performance in general. Additional colors and information not only allow you to better navigate the editing process, but also have an aesthetic component.

" color scheme setup
let g:sonokai_style="default"
let g:sonokai_better_performance = 1

let g:airline_theme="sonokai"
let g:airline#extensions#tabline#enabled = 1
let g:airline_powerline_fonts = 1
let g:sonokai_transparent_background = 1
let g:sonokai_diagnostic_text_highlight = 1
let g:sonokai_spell_foreground = 'colored'

" color scheme with enabled plugins
colorscheme sonokai

" scheme fine tuning
hi Comment guifg=#707070 ctermfg=darkgray
hi Visual guifg=#333333 guibg=darkgray

Of course, which particular color scheme is pleasing to the user’s eye is a subjective and personal matter. True, one thing – native 16 color schemes, whatever one may say, cannot cover the entire spectrum of modern lighting tasks. It should be noted that :set termguicolors may change the palette somewhat, so it must be consistent in some way. Or you can disable this option.

Instead of conclusions

Next, at the bottom of the plugin configuration, I will put (auto) commands and some additional settings.

" Commands and functions

" change current dir to project root on open
function! <SID>AutoProjectRootCD()
      if &ft != 'help'
      " Silently ignore invalid buffers
autocmd BufEnter * call <SID>AutoProjectRootCD()

For example, this one sets the current directory to the project root automatically. If, of course, there is one.

Vim without plugins is still powerful and in some sense quite convenient editor, but it makes no sense to forcefully avoid using them. The following formula works for me: see how it works in other editors, look for a plugin that implements the functionality you like and try to get by with built-in tools. If it doesn’t work at all or it’s very difficult, then install a plugin. Immediately grab everything that people advise for some reason should not be. I sincerely believe that each additional extension must be reached independently. On the other hand, one must imagine what is possible in principle and how it happens.

In the next part, we should probably dwell on one more intermediate step, without which the creation of your own IDE may go to the wrong steppe. Perhaps it will be necessary to dwell in more detail on filetype, built-in autocompletion, buffer management, windows and tabs. In the meantime, please leave in the comments to the article which plugins you think should be included in the minimum and more or less universal set.


Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *