Perf

[sainnhe]

This PR will add a new option g:gruvbox_material_better_performance, it reduces the loading time by generating files in the ftplugin directory, so that part of the code can be loaded on demand.

Test:

$ nvim colors/gruvbox-material.vim --startuptime log

With this feature disabled:

063.959  000.142  000.142: sourcing /home/sainnhe/.local/share/nvim/plugins/gruvbox-material/autoload/gruvbox_material.vim
085.685  024.555  023.879: sourcing /home/sainnhe/.local/share/nvim/plugins/gruvbox-material/colors/gruvbox-material.vim
087.963  001.795  001.558: sourcing /home/sainnhe/.local/share/nvim/plugins/gruvbox-material/autoload/lightline/colorscheme/gruvbox_material.vim

With this feature enabled:

056.133  000.147  000.147: sourcing /home/sainnhe/.local/share/nvim/plugins/gruvbox-material/autoload/gruvbox_material.vim
060.693  006.315  005.844: sourcing /home/sainnhe/.local/share/nvim/plugins/gruvbox-material/colors/gruvbox-material.vim
062.815  001.703  001.480: sourcing /home/sainnhe/.local/share/nvim/plugins/gruvbox-material/autoload/lightline/colorscheme/gruvbox_material.vim
145.476  000.359  000.359: sourcing /home/sainnhe/.local/share/nvim/plugins/gruvbox-material/ftplugin/vim/gruvbox_material.vim

[sainnhe]

There is a very strange bug in this feature: When a completion item is triggered by coc in neovim, the after/ftplugin directory will be deleted. This bug doesn't exist in vim.

Steps to reproduce:

Version

NVIM v0.4.3
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O2 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/build/neovim/src/build/config -I/build/neovim/src/neovim-0.4.3/src -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovim/src/build/include
Compiled by builduser

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info

Minimal vimrc

if has('nvim')
  set runtimepath^=~/.vim runtimepath+=~/.vim/after
  let &packpath = &runtimepath
endif

call plug#begin('~/.local/share/nvim/plugins')
Plug 'sainnhe/gruvbox-material', {'branch': 'perf'}
Plug 'neoclide/coc.nvim', {'do': 'yarn install --frozen-lockfile'}
call plug#end()

set termguicolors
set background=dark
let g:gruvbox_material_better_performance = 1
colorscheme gruvbox-material

if !has('win32')
  let g:coc_data_home = expand('~/.local/share/coc.nvim')
endif
let g:coc_global_extensions = [
      \   'coc-lists',
      \   'coc-vimlsp'
      \   ]

Steps:

1. Install the plugins and coc extensions.
2. Open a vim file: $ nvim test.vim
3. Insert some text and press <C-n> to select the first item.
4. The ~/.local/share/nvim/plugins/gruvbox-material/after/ftplugin directory has been deleted.

Some analysis

First of all, this bug is nvim only, I can't reproduce it in vim.

And, I found that it's related to the builtin delete() function. If you comment out the delete() function in L353-L377,this bug will disappear.

But what's interesting is that during the deletion of after/ftplugin, the gruvbox_material#ft_clean() function will not be called. You can add some test code like echom 'foo' in this function and see what will happen.

In addition, I found that the commit 34219c29 in coc produces this bug, it won't appear in the version earlier than 34219c29.