Vim: 对目录中的文件应用设置

如何为工作目录下的所有文件指定 Vim 设置？

理想的解决方案是，如果 Vim 搜索并读取。在搜索 ~/之前，在工作目录中搜索 vimrc。然后应用整个树的设置。

我见过一个 插件，但这意味着应用程序的设置是不透明的，因为他们需要安装插件。相比之下，deline 是透明的，因为不管用户的 vimrc 或特定的 vim 调用如何，deline 设置都将应用于该文件。

我试过的东西

  • 在工作目录里放一个 vimrc
  • 模型中的 :so vimrc。

我想两者都不是出于安全原因。我不需要 vimrc 的全部功能; 只要绑定到 Modeline 可以接受的设置就足够了。我的目标是让 vimmer 更容易在项目中采用编码标准。

29636 次浏览
小开

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

小开

You can put something like this in $VIM/vimrc

autocmd BufNewFile,BufRead /path/to/files/* set nowrap tabstop=4 shiftwidth=4
小开
最佳答案

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 be used to source a single configuration file. This is very similar to the plugin approach except the .vimrc has to be parasited with non global options, and it does not support easily multiple/shared configuration files.

小开

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

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

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

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

小开

I'd strongly suggest not using set exrc

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

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

you'll probably be less amused than I will.

小开

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

Eg.

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

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

if filereadable("_gvimrc")
source _gvimrc
endif

at the end.

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

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

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

小开

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

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

小开

I agree with the plugin approach for security reasons.

There is a very good plugin which has not been mentioned yet. It lets you 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

小开

I looked at the plugins that existed and didn't really fancy any of them, so I wrote a simple function that piggy backs on vim-fugitive. The advantage of this is that it knows the root of the project is always the root of the repository, and additionally I can hash the file to keep a trust table. Just put 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 is set on the viminfo setting, then the SAFE_VIMRC dictionary will be preserved between runs (note the ^ to prepend the option so it doesn't mess up the n option).

小开

Use "editorconfig"

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

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

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

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


提交答案