[ACCEPTED]-Vim: apply settings on files in directory-vim

You can put something like this in $VIM/vimrc

autocmd BufNewFile,BufRead /path/to/files/* set nowrap tabstop=4 shiftwidth=4

0

I'd strongly suggest not using set exrc

Even with 5 set secure, under *nix, vim will still run autocommands, shell, et 4 al, if you own the file. So if you happend 3 to edit a file in that tarball I sent you 2 with a .vimrc containing:

autocmd BufEnter * :silent! !echo rm -rf ~/

you'll probably be less 1 amused than I will.

I'm an advocate of the plugin way. For several reasons:

• Modelines are particularly limited: we can't set variables (that tunes other (ft)plugins, like "should the braces of the for-snippet be on a newline ?"), or call function from them (I don't limit myself to coding standards, I also set the makefile to use depending on the current directory)
• DRY: with modelines, a setting needs to be repeated in every file, if there are too many things to set or tunings to change, it will quickly become difficult to maintain, moreover, it will require the use of a template-expander plugin (which you should consider if you have several vimmers in your project).
• Not every one uses vim to develop. I don't want to be bothered by other people editor settings, why should I parasite theirs?
• It's easier to ask vimmers to install a same plugin, instead of asking them to copy-paste, and maintain, the same lines in their .vimrc
• The settings can be saved with the other project files (cvs/svn/git/whatever)
• It's really easy to have a configuration file per project -- with the plugin, I have a global configuration file for the coding standards of the overall project, and specific configuration files for each sub-project (which makefile to use, which executable to call, ...)

BTW, sth's solution can 6 be used to source a single configuration 5 file. This is very similar to the plugin 4 approach except the .vimrc has to be parasited 3 with non global options, and it does not 2 support easily multiple/shared configuration 1 files.

This question is old, but it seems like 14 a pretty natural and persistent concern.

My 13 solution is pretty simple. I place a .vimrc file 12 in the root directory of my projects. The 11 first line of the .vimrc file usually sources 10 ~/.vimrc, and then adds the particular configuration 9 I want. I alias tvim='vim -u .vimrc', and use tvim in my personal 8 project directories. "tvim" for "trusted 7 vim," meaning that if I execute it in a 6 directory with a .vimrc file and something goes 5 wrong, I've got no one to blame but myself, since 4 I explicitly said I trusted it. Also, I 3 keep a group of these stored away so that 2 I can sometimes just softlink the one I 1 want for a particular kind of project.

Placing a .vimrc in the working directory 11 actually is supported, only disabled by 10 default. See :h 'exrc' and :h startup for details, setting 9 'exrc' will enable reading .vimrc from the current directory.

It's 8 also recommended to :set secure when using this. This 7 locks down :autocmd, shell and write commands for 6 .vimrc in the current directory.

Another thing 5 that might be worth looking at is setting 4 up a session (:h session) with a standard view and 3 settings for the project.

All that said, I 2 would probably go with the plugin option 1 detailed by Luc Hermitte myself.

To minimize security risks with ANY "autorun" features 27 for ANYTHING these days, may I advise you 26 to utilize vim's existing features instead 25 of plugins (portability baggage)?

Eg.

My local 24 folder's vimrc file is named "_gvimrc" (on 23 purpose). This reduces the hope for people 22 like phen from amusing himself at our expense. :-)

In 21 my $VIM/.vimrc file, I inserted:

if filereadable("_gvimrc")
    source _gvimrc
endif

at the end.

I 20 use "filereadable()" over "fileexists()" as 19 the later has some quirkiness when tortured 18 with opening multiple (10+) files simultaneously, (not 17 sure why).

Of course, you can give your own 16 unique filename to obfuscate potential trouble-makers 15 further. Such as "_mygvimrc", "_gobbledygook", etc. You 14 just need to settle on one standardized 13 name and source it accordingly in your $VIM/.vimrc. Relying 12 on vi/vim internals for this rules out portability 11 issues. BUT, DO NOT name it .vimrc (or _vimrc) to 10 prevent recursive sourcing in case you're 9 editing the $VIM/.vimrc file with vim later.

Been 8 using this since Windoze 98SE, through Windork 7 XP Pro, and now Windorkier 7 (5+ years already). I'll 6 mark a list of .txt files in Explorer and 5 then use "Edit with multiple Vim", resulting 4 in multiple vim windows opening simultaneously. For 3 my work, I do this several times a day, daily. All 2 files got treated with what I set in my 1 local _gvimrc.

Use "editorconfig"

If the kinds of coding standards you would 23 like to enforce are related to indentation 22 style, tab size, file format and charset, then 21 you might want to look into "editorconfig", which is a 20 cross-editor standard to specify this kind 19 of settings in a specific project, and have 18 all editors follow that configuration.

The 17 "editorconfig" specification allows 16 projects to request different settings depending 15 on file extensions or names within the project. (So 14 you can have Makefiles using TABs, your 13 Python scripts using 4 spaces and your shell 12 scripts using 2 spaces for indentation.)

You 11 need a plug-in to use "editorconfig" in 10 Vim. The official website provides one, but 9 personally I'd recommend sgur/vim-editorconfig, which is written 8 in pure Vimscript, so you don't need to 7 worry about external dependencies too much.

Since 6 "editorconfig" aims at cross-editor 5 compatibility, it's quite limited in what 4 it does, so if you want is consistent whitespace, file 3 format (DOS vs. Unix) and encoding (Unicode 2 utf-8, etc.), then "editorconfig" is 1 for you.

Assuming people aren't adding files every 6 few days, you can probably add a modeline 5 at the top of each file. In fact, if your 4 version control system allows it, you could 3 probably enforce a rule that says that each 2 file must have a modeline when it's checked 1 in.

I agree with the plugin approach for security 3 reasons.

There is a very good plugin which 2 has not been mentioned yet. It lets you 1 use a .lvimrc in your project directories.

Try "localvimrc" out:

http://www.vim.org/scripts/script.php?script_id=441

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

Try vim-localrc

~/
|- .local.vimrc     (1)
`- project/
   |- .local.vimrc  (2)
   `- src/
      |- .local.vimrc   (3)
      `- main.c

https://github.com/thinca/vim-localrc/blob/master/doc/localrc.txt

0

I looked at the plugins that existed and 11 didn't really fancy any of them, so I wrote 10 a simple function that piggy backs on vim-fugitive. The 9 advantage of this is that it knows the root 8 of the project is always the root of the 7 repository, and additionally I can hash 6 the file to keep a trust table. Just put 5 the following in your .vimrc file.

function LoadRepoVimrc()
  let l:path = fugitive#repo().tree('.vimrc')
  if filereadable(l:path)
    let l:sha1 = fugitive#repo().git_chomp('hash-object',l:path)
    if !exists('g:SAFE_VIMRC') | let g:SAFE_VIMRC = {} | endif
    if has_key(g:SAFE_VIMRC,l:path) && g:SAFE_VIMRC[l:path] ==? l:sha1
      execute 'source '.fnameescape(l:path)
    elseif confirm("Trust ".l:path."?", "&Yes\n&No",2) == 1
      let g:SAFE_VIMRC[l:path] = l:sha1
      execute 'source '.fnameescape(l:path)
    else
      execute 'sandbox source '.fnameescape(l:path)
    endif
  endif
endfunction
autocmd User FugitiveBoot call LoadRepoVimrc()
set viminfo ^= !

If the ! option 4 is set on the viminfo setting, then the SAFE_VIMRC dictionary 3 will be preserved between runs (note the 2 ^ to prepend the option so it doesn't mess 1 up the n option).