I have a question regarding the following situation:

I want to use a default .vimrc and a vimrc (name it .vimrc2) for a special purpose.

However, when I start vim with

vim -u ~/.vimrc2

I have the following problem: Plugins (I use vim-plug), which are specified in .vimrc (especially UltiSnips) will not be loaded if I run the command above. I have tried to include the code from .vimrc:

call plug#begin()
Plug 'sirver/ultisnips'
let g:UltiSnipsUsePythonVersion = 3
    let g:UltiSnipsExpandTrigger = '<tab>'
    let g:UltiSnipsJumpForwardTrigger = '<tab>'
    let g:UltiSnipsJumpBackwardTrigger = '<s-tab>'
call plug#end()

into my .vimrc2 file, but it doesn't help.

How can I configure my system such that snippets (and other plugins) will be loaded, no matter which .vimrc file I use?

Plugins are at ~/.vim/plugged and snippets at ~/.vim

Running :scriptnames gives me:

1: ~/.vimrcforinkscape
  2: ~/.vim/autoload/plug.vim
  3: /usr/share/vim/vim81/filetype.vim
  4: ~/.vim/ftdetect/snippets.vim
  5: ~/.vim/plugged/ultisnips/ftdetect/snippets.vim
  6: /usr/share/vim/vim81/ftplugin.vim
  7: /usr/share/vim/vim81/indent.vim
  8: /usr/share/vim/vim81/syntax/syntax.vim
  9: /usr/share/vim/vim81/syntax/synload.vim
 10: /usr/share/vim/vim81/syntax/syncolor.vim
 11: ~/.vim/plugged/ultisnips/plugin/UltiSnips.vim
 12: /usr/share/vim/vim81/plugin/getscriptPlugin.vim
 13: /usr/share/vim/vim81/plugin/gzip.vim
 14: /usr/share/vim/vim81/plugin/logiPat.vim
 15: /usr/share/vim/vim81/plugin/manpager.vim
 16: /usr/share/vim/vim81/plugin/matchparen.vim
 17: /usr/share/vim/vim81/plugin/netrwPlugin.vim
 18: /usr/share/vim/vim81/plugin/rrhelper.vim
 19: /usr/share/vim/vim81/plugin/spellfile.vim
 20: /usr/share/vim/vim81/plugin/tarPlugin.vim
 21: /usr/share/vim/vim81/plugin/tohtml.vim
 22: /usr/share/vim/vim81/plugin/vimballPlugin.vim
 23: /usr/share/vim/vim81/plugin/zipPlugin.vim
 24: ~/.vim/plugged/ultisnips/after/plugin/UltiSnips_after.vim
 25: /usr/share/vim/vim81/autoload/dist/ft.vim
 26: /usr/share/vim/vim81/ftplugin/tex.vim
 27: /usr/share/vim/vim81/ftplugin/plaintex.vim
 28: /usr/share/vim/vim81/ftplugin/initex.vim
 29: /usr/share/vim/vim81/indent/tex.vim
 30: /usr/share/vim/vim81/syntax/tex.vim
  • I find it odd that including the plug-in configuration in your .vimrc2 wouldn't work... If you use :scriptnames in that setup, do you not see the plug-in files in ultisnips being called? – filbranden Sep 16 '19 at 0:26
  • See my edits for the output of :scriptnames. :PlugInstall tells me that UltiSnips is installed. – Aericura Sep 16 '19 at 0:37
  • That line with 11: ~/.vim/plugged/ultisnips/plugin/UltiSnips.vim tells me UltiSnips is being installed... Why do you say it's not working? Perhaps it's not loading the snippets from the right location? Where do you have your snippets, is that location configured in your original .vimrc? – filbranden Sep 16 '19 at 0:43
  • As I said, the .snippets file is in ~/.vim, it worked out of the box in this way. Would it be smarter to define a directory? The location is not configured in .vimrc – Aericura Sep 16 '19 at 0:44
  • 1
    @eyal karni Conditions are a very good idea! Thank you for that, I'm running the .vimrc2 in a seperate terminal anyways, so I could check for that! – Aericura Sep 16 '19 at 9:13

Set nocompatible

When you use a separate vimrc through the -u command-line flag, the nocompatible option will not be automatically set, as it is when using the normal user vimrc file.

See :help compatible-default for more details.

You should either add set nocompatible to the top of your alternative vimrc file, or pass Vim the -N command-line option in addition to -u when using an alternative vimrc file.

Thanks @Rich for figuring out nocompatible was likely the issue here, later confirmed by @Aericura.

Plug-ins are loading, just not working

Your listing of :scriptnames shows that the UltiSnips plug-in is being loaded. The fact that it isn't working for you seems to be unrelated to passing an alternative vimrc file through the -u option, but probably due to some command from your original vimrc that's missing from your alternative vimrc and that you didn't realize was important to make UltiSnips work for you.

You might want to do a few experiments, such as copying your original vimrc file (which is working) to a different name and passing that new file to the -u flag. You should see that this configuration will be working, same as your original vimrc.

Another experiment is to make a back up copy of your original vimrc and deploy your alternative one in its place, as ~/.vimrc (assuming that's the path of your original vimrc file.) You should verify that this setup is also not working, same as starting Vim with the alternate vimrc through the -u flag.

If you check that this is indeed the case, then try to figure out what else is missing from your original vimrc to make UltiSnips work. You seem to be copying the global variables already, so that's probably not it... Do you perhaps have any key mappings to functions defined by UltiSnips that you're missing?

Make sure you're in nocompatible mode as well, maybe add set nocompatible to the top of your alternative vimrc. Make sure you also enable filetype processing, with filetype plugin indent on. (It's unlikely one of these is the cause of your issue, but it's worth mentioning since they're easy to try.)

Sharing vim-plug configuration

Same plugins for every .vimrc file (vim-plug)

Answering your question from the title, having the same vim-plug stanza in every vimrc file should be enough to load the same plug-ins on Vim regardless of which .vimrc you're using, either the paths searched by default, or through the -u command-line flag.

If you want to avoid repeating that information into multiple vimrc files, consider storing it on a separate file, such as ~/.vim/load-plugins.vim and loading it using :source or :runtime.

If you store it in the location above, then this command should be enough to load it:

runtime load-plugins.vim

Add the command above to all your vimrc alternatives, they will then share the same plug-ins and same plug-in configuration (assuming you also keep the configuration for the plug-ins in that same file.)

Alternative: packages

If you're using Vim 8 or higher, or NeoVim, then consider using Vim packages instead of a plug-in manager such as vim-plug.

Your plug-ins are loaded from a standard location under your ~/.vim, so you don't need any configuration in your .vimrc to load the plug-ins, so that also solves that problem.

One difference between a plug-in manager such as vim-plug and native packages is that the former is able to install and update plug-ins for you (typically from Git repositories), while with packages it's on you to download them or git clone them in the proper location and to update them there.

See this excellent answer with a description of packages and instructions on how to use them.

There should be only one

Finally, take a closer look at the reasons why you're using a separate vimrc. Are you using it to edit specific types of files?

In many cases, you might be able to trigger the specific kind of behavior you're customizing by triggering it based on the type of file you're editing. (Or you can use other specific triggers to enable your custom behavior.) That should prevent the whole "maintaining multiple vimrc files" mess. It should also make it easier to reuse your customizations for a specific filetype in other situations, other machines (not really tied to your custom vimrc.)

If you're interested in this approach, I suggest you ask further questions here, detailing your particular use case and trigger, to get help into how you can refactor that into a set of filetype-specific customizations.

  • 1
    I think is likely that nocompatible is the problem. Many plugins check for this before doing anything, no? edit: including ultisnips Probably worth explaining why this will be unset in the user's situation? – Rich Sep 17 '19 at 10:58
  • 1
    compatible is set if -u is used to specify a vimrc file (in the version that I'm using, at least). – Rich Sep 17 '19 at 11:18
  • 1
    In case it's not clear, -u not setting nocompatible is what I was alluding to when I suggested explaining why compatible would be set for the user. – Rich Sep 17 '19 at 11:20
  • 1
    Thanks, it was indeed the nocompatible option that was missing. Sometimes, "the devil is in the details", as we Germans say :))) – Aericura Sep 17 '19 at 12:43
  • 1
    And I think in my case, a seperate .vimrc is helpful. The situation is as follows: I open Inkscape and I press a button to open terminal with -e vim and for that, vim should be in insert mode and in a fixed line at the beginning. In order to avoid an if statement in the usually used .vimrc and reverting all settings with :no..., it is easier for me to do it with a seperate .vimrc. Thank you! – Aericura Sep 17 '19 at 12:47

Your Answer

