Local Vimrc

Oct 29, 2017 12:07 · 376 words · 2 minutes read Testing Vim

In one of my previous posts I talked a little bit about how I was having trouble switching between projects and continuing to run unit test coverage. This is because you have to specify the module that you want to cover as part of the options passed into pytest.

I toyed around with the idea of auto-discovering the module name, but I later came across a more flexible idea. In Vim there’s a way to load additional configurations from other .vimrc files. This lets you specify a base vimrc for all of your regular editing and customize the functionality per-project. You can check the original post I read about this idea.

The problem with this is the security implications. Theres a couple of good answers on Stack Overflow about why this is a bad idea. For me it really comes down to the fact that you can’t see when there’s going to be an issue before it happens. For projects that I own and maintain, I know there’s nothing malicious in these .vimrc files. I wrote them after all. It’s the other projects that are concerning. Because the exrc option has to be turned on globally to work, it’ll automatically source the .vimrc files for any project. So if I somehow miss that I’m sourcing it, and forget to read it or block it before hand, anything could potentially happen. As the Stack Overflow post illustrates, even setting the secure flag is not a guarantee of safety.

What ended up working well for me was using the localvimrc plugin. By default localvimrc sources any .lvimrc files (which are the same as .vimrc files, just by a different name to differentiate them for the plugin’s sake). If it discovers a .lvimrc file in the directory that you are editing files in, it will ask whether or not you want to source it. You can choose to source it right away, or check the file contents inside the current editor buffer.

The really killer feature is the ability to remember .lvimrc files that you have sourced previously. There’s a ton of other options for the plugin, including whitelists and blacklists. It’s a much better balance between wanting per-project configurations for vim and dealing effectively with the security implications.