1

I want to split up my .vimrc into multiple files by language or toolchain, use case, etc.

In fact, my end goal is to be able to provide instructions to students in the format of "If you want the same settings I have, just do this: curl https://example.com/vim/foobar.vim -o ~/.vim/xxxxx/foobar.vim".

I know that as of vim 8 we can now use ~/.vim/pack/XXXX/start/ to put plugins without requiring a 3rd party loader. However, when I tried moving some of the things from my .vimrc there as ~/.vim/pack/plugins/start/go.vim (my settings for golang) it didn't seem to load my settings anymore, even though I had packloadall in my .vimrc.

Is it possible to drop a file into a folder and have it load? Do I need to declare what it depends on in some way?

Similar Question

I'm aware of Is it possible and useful to split vimrc?, but that doesn't seem to address the new features of vim 8.

I'm looking to find a solution that doesn't require additional manual edits to .vimrc, and I believe that with vim 8 such a thing exists.

3
  • Have you read :h packages?
    – Matt
    Aug 14, 2020 at 5:46
  • Haha, I don't think I've ever :h anything in my whole life. I'm just use vim, I've never made anything special before. Thanks for pointing me in the right direction. I'll post my hacky solution and I'll appreciate it if you have any better light to shed on the problem.
    – coolaj86
    Aug 14, 2020 at 6:06
  • 3
    if you just want to have filetype specific settings, I recommend to put those into ~/.vim/after/ftplugin/<filetype>.vim No need for packages in this case Aug 14, 2020 at 6:10

2 Answers 2

2

Without newish packages feature you can use ~/.vim/plugin/ folder.

All vim files you have in this folder are auto sourced using :h :runtime:

I do exactly this for my settings:

  1. main vimrc is ~45 lines having only core options
  2. separate ~/.vim/plugin/mappings.vim file for mappings and commands
  3. other separate vim files (foldtext setup, terminal setup etc)

Example: https://github.com/habamax/.vim/tree/master/plugin

PS, .vim folder has the structure of a packaged plugin where you can have ftplugins, syntax, lazy loaded autoloads, filetype detection, etc. I remember long time ago all plugins were copied into mentioned .vim subfolders and it was a mess.

1
  • Ah, you must be one of the ancients. 🧙‍♂️🙏
    – coolaj86
    Aug 25, 2020 at 23:28
0

Create a "vimrc" plugin

I don't know if this is a "good" way to do it, but this seems to work:

  • Create a "vimrc" plugin at ~/.vim/pack/plugins/start/vimrc
  • Add its pieces to ~/.vim/pack/plugins/start/vimrc/plugin/{foo,bar,baz}.vim

Example

mkdir -p ~/.vim/pack/plugins/start/vimrc/plugin/
cat <<EOF > ~/.vim/pack/plugins/start/vimrc/plugin/go.vim
let g:syntastic_go_checkers = ['go', 'golint', 'errcheck']
let g:go_fmt_command = "goimports"
EOF

It's fine that this always loads because it's only setting variables and syntastic is only loading all of its stuff that uses the variables based on the filetype anyway.

See also

The comment in the question about the "after" ftplugin, and https://vim.fandom.com/wiki/Keep_your_vimrc_file_clean

2
  • This is often problematic, since it might depend on this specific plug-in being loaded before other plug-ins, if it's setting some variables that other plug-ins consume at the time of their startup... It might not be the case for the two that you mentioned, but I'd be hesitant to recommend this as a general approach... Instead, just store separate *.vim files elsewhere under ~/.vim (a non-special subdirectory) and use explicit source commands for them.
    – filbranden
    Aug 14, 2020 at 17:41
  • 1
    While I don't disagree that such edge cases exist (and perhaps for power-users are not edge cases, but daily occurences), that goes against the plug-n-play goal that I'm trying to achieve. I'd say that an at least equally reasonable approach would be that anyone making such files be aware of the caveat and make sure that the things that they split-up are truly separate concerns and not intertwined.
    – coolaj86
    Aug 14, 2020 at 19:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.