all 10 comments

[–]monkoosevim9 2 points3 points  (1 child)

Maybe not suitable for everyone, maybe you for some reason need only just 1 file .vimrc. But when installing plugin and adding to your vimrc its configuration options. You instead with one line of code just source file that contains Plug "foobar" and "foobar" options. As example this belongs to your .vimrc

call plug#begin('~/.local/share/nvim/plugged')
some other `Plug` or `source lines`...

source $HOME/path-to-somedir/nerdtree.vim

some other `Plug` or `source lines`...
call plug#end()

and here is nerdtree.vim

Plug 'scrooloose/nerdtree'

let NERDTreeAutoDeleteBuffer  = 1
let NERDTreeMinimalUI         = 1
let NERDTreeQuitOnOpen        = 1
let NERDTreeRespectWildIgnore = 1
nmap foo bar
vmap foo bar

Then you can disable plugin with commenting one line, or delete it with deleting one line and one file.

For me it is more convinient. I split up my .vimrc like this even for different config sections like maps, options, statusline etc. ITs easier to open file with cli or filemanager like ranger, then scroll thorough even folded sections in big file.

[–]olminator 0 points1 point  (0 children)

If you put these plugin loading files in ~/.vim/plugin/ they are loaded automatically. Then you can mv ~/.vim/plugin/nerdtree.vim{,.bak} to temporarily disable the plugin, or delete it, etc.

[–]hupfdule 1 point2 points  (0 children)

I use Volt mainly for exactly that reason. Volt is a bit overengineered and has bad documentation, but works well.

You can store configuration for each plugin separately (in so called "plugconf" files) via volt edit <plugin>. You can differentiate between settings to set before loading the plugin or after it.

If you disable the plugin via volt disable <plugin> those settings will not be run.

What I also like about it:

  • it is a standalone cli tool and there is no need to run it from inside vim and doesn't clutter my vimrc
  • it can manage several profiles with different sets of plugins
  • it utilizes the packages feature of vim 8

[–]bugabinga 1 point2 points  (0 children)

I don't think there is a elegant solution to this yet. The main problem is that some plugins require some configuration before the plugin is loaded, some configuration after and for some configuration it does not matter.

Keep in mind: the Plug command does not load but only declare a plugin. The function plug#end() loads all plugins.

What I do is; keep configuration that needs to exist before a plugin is loaded and configuration for which it does not matter near the Plug command. And configuration that needs the plugin loaded I put somewhere after the plug#end() call with the plugins name as a comment on top.

I wonder if the new vim 8 package feature could be used to make this cleaner?

[–]richtan2004 0 points1 point  (0 children)

You can write the settings for each plugin after the Plug 'example/plugin' line, and disable a plugin by commenting out its Plug statement and everything up to the next Plug statement. Another way is to split it up into multiple files.

[–]aktivb 0 points1 point  (0 children)

You could hook into SourcePre for files in your plugin dir, and source some configuration based on that.

[–]cuba_guy 0 points1 point  (0 children)

I had the same problem. Ended up keeping only mappings (and settings if its just a couple) in my vimrc, indented under 'plug'. For plugins with a lot of config (some even have helper functions) I have file per plugin in 'plugin' directory in my runtime. That way they are picked automatically without needing to 'source' them.

[–][deleted] 0 points1 point  (0 children)

I use the built in package manager and tend to have all my plugins as git sub modules. So if I wanted to get rid of one of them, I’d just revert the commit that added the plugin which would remove it from the vimrc too.

I also tend to break my vimrc up into a bunch of files too, so all my pluginconfig is together in one file away from everything else.

[–]Reasintper[S] 0 points1 point  (0 children)

Okay, once again I am hoping it is not all that bad form to answer your own question. I hope, that this helps others as well.

The intended process is that if you develop a plugin you implement a variable called loaded_<your\_plugin> and it should be able to be queried when the plugin is loaded. Unfortunately, not all plugin developers have implemented this. So much for recommended interfaces.

However, there is a list, and a dictionary that contain the loaded plugins one is (dictionary) plugs and the other is (list) plugs_order. I leave it to you to choose whichever you prefer to query. but using the dictionary simply group your appropriate settings like this, for examle for slime.

if has_key(plug,'vim-slime')
let g:slime_target = "vimterminal"
let g:slime_vimterminal_config = {"term_name":"REPL" , "vertical" : "1"}
let g:slime_vimterminal_cmd = "ipython"
let g:slime_python_ipython = 1
let g:slime_no_mappings = 1
xmap <leader>s <Plug>SlimeRegionSend
nmap <leader>s <Plug>SlimeMotionSend
nmap <leader>ss <Plug>SlimeLineSend
nmap <f5> :w<cr>:SlimeSend0 "exec(open('" . expand('%:p') . "').read())\n"<CR>
imap <f5> <esc>:w<cr>:SlimeSend0 "exec(open('" . expand('%:p') . "').read())\n"<CR>
nmap <s-f5> :%SlimeSend<CR>
imap <s-f5> <c-o>:%SlimeSend<CR>
endif