11

Is there a way to make certain vimrc configuration valid only for files under a defined directory tree? Or alternatively, is there a way to have a .vimrc file in a directory, and make its setting override all $HOME/.vimrc for that directory and subdirectories (and maybe, additional vimrc file in subdirectory would override again what was overridden by the directory-tree-root vimrc) ?

Like this:

- ~
+- .vimrc
+- Development
   +- proj
      +- src 
         +- .vimrc (overrides ~/.vimrc for files in Development/proj/src and subdirs)
      +- res
         +- .vimrc (overrides ~/.vimrc for files in Development/proj/res and subdirs)
         +- cc
            +- .vimrc (overrides ../.vimrc and ~/.vimrc for files in Development/proj/res/cc)
Improve this question
7
  • 4
    You are aware that a vimrc can do anything? e.g., it can execute arbitrary commands such as rm -Rf $HOME. You do not want to source an untrusted vimrc.
    – derobert
    Commented Feb 22, 2015 at 6:03
  • 1
    vim.org/scripts/script.php?script_id=441
    – muru
    Commented Feb 22, 2015 at 6:17
  • 2
    @derobert I am not very concerned with that; if someone breaks in and drops a random .vimrc, well he did already breakin end of the day; if it is stuff coming from a src control repo, and i pull or rebase without noticing, then it would be me to blame, like downloading a random piece of software, make and execute.
    – guido
    Commented Feb 22, 2015 at 7:06
  • 2
    Related: Vim: apply settings on files in directory at stackoverflow SE
    – kenorb
    Commented Feb 22, 2015 at 13:08
  • 1
    @Carpetsmoker it seems i can delete (even if there is an accepted answer, weird); probably i cannot vote because i haven't enough reputation. Please do if you can, actually the question wording is quite different so it may still be worthy
    – guido
    Commented Feb 22, 2015 at 21:56

2 Answers 2

Reset to default
11

There are several ways to do this.

As you specified directory tree, it excludes the .exrc approach (as it only works for one directory), and the modelines as well.

Remains the hand-rolled way: you put an autocommand in your .vimrc for pattern or specific directories. It's not my preferred approach as it clutters the .vimrc with yet another thing -- and also because my mind have been compromised with the Single Responsibility Principle.

For reference, there is also the plugin Project -- one of the oldest on vim.org. As I'm not using it, I won't detail how it works.

Then, there are many, and many, plugins with a name that looks like local vimrc. I've even been maintaining one for years: https://github.com/LucHermitte/local_vimrc

Regarding its features,

  • It answers your question: being sourced for each file in a hierarchy -- actually each time we enter a related vim window, the matching _vimrc_local files are sourced.
  • The plugin will look for files named _vimrc_local.vim, though the pattern used to search for files can be configured (as a string or a list of patterns)
  • It permit plugins that uses per project settings to force loading the _vimrc_local file before anything else. For instance, when I run gvim foobar.cpp from the shell my template expander plugin (TEP) (mu-template) automatically fills in the project name, the project style (copyright headers, namespaces, naming conventions, ...). As TEP and vimrc_local plugins usually use the same vim event, there is a race on the event, and there is no guaranty project settings can be loaded before expanding any template. So, there is a way with my plugin to fix this kind of races.
  • On the official site, you'll found some explanations on how to write the _vimrc_local.vim project files.
  • It's being regularly tested and used on Windows (with/without cygwin), *nixes.
  • It stops searching for project configuration at $HOME, or the root directory (/, //ip/), or don't even try to on remote files (http, ftp, ...).
  • It supports black and white lists, and also ask-to-the-user and sandbox lists which will work in the same way: what is done of the project-file will depend on the kind the list the project-file belongs to.
  • Someday, I'll eventually have templates to generate project configurations for C & C++ project managed with/without CMake, generating (or not) Doxygen documentation, ...
Improve this answer
3
  • 2
    +1 ... Does your local-vimrc plugin prevent some of the security issues that could happen? For example, I often download or checkout the source of a project (including small ones) to investigate something. Anyone could put a .localvimrc in that, and do all sorts of evil stuff, or other, non-malicious, harmful things, like maybe system('rm -rf /$HOME/$UNDEFINED_ON_MY_SYSTEM') or some such...
    – Martin Tournoij
    Commented Feb 23, 2015 at 17:19
  • Yes and No, it does nothing to prevent to code to execute. However, you could force the pattern searched (g:local_vimrc) to something that makes no sense as you are opening vim. This will require some knowledge about how to launch vim with parameters. I guess, I'd better add blacklists and such to permit to emulate sandboxes. This would be easier to open files from unsecured projects. My next eventual course of action for this plugin was to permit to support vimrc_local outside of the current directory.
    – Luc Hermitte
    Commented Feb 23, 2015 at 18:05
  • 2
    Fixed. Now, blacklists & co are supported.
    – Luc Hermitte
    Commented Mar 3, 2015 at 18:39
1

I've used the LocalVimrc plugin with success, very handy indeed!

https://github.com/embear/vim-localvimrc

Improve this answer
1

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