Vim: aplica configurações em arquivos no diretório

Como eu especifico as configurações do Vim para todos os arquivos no diretório atual?

A solução ideal seria se o Vim pesquisasse e lesse um arquivo .vimrc no diretório atual antes de procurar por ~ / .vimrc e aplicasse as configurações lá para a tree inteira.

Eu vi um plugin , mas isso significa que as configurações aplicadas não são transparentes, pois exigem que o plugin seja instalado. Por outro lado, uma modeline é transparente, pois, independentemente do vimrc de um usuário ou da chamada vim específica, as configurações de modeline serão aplicadas a esse arquivo.

Coisas que eu tentei

  • colocando um .vimrc no diretório de trabalho
  • :so vimrc na modeline.

Eu suponho que ambos não funcionam por razões de segurança. Eu não preciso do poder total de um vimrc; estar ligado a configurações aceitáveis ​​por uma modeline seria suficiente. Meu objective é tornar mais fácil para os vimmers adotarem padrões de codificação em um projeto.

Eu sou um defensor da maneira do plugin . Por várias razões:

  • Modelines são particularmente limitadas: não podemos definir variables ​​(que sintonizam outros (ft) plugins, como “as chaves do for-snippet devem estar em uma nova linha?”), Ou chamar a function delas (eu não me limito para os padrões de codificação, eu também defino o makefile para usar dependendo do diretório atual)
  • DRY : com modelines, uma configuração precisa ser repetida em cada arquivo, se houver muitas coisas para definir ou ajustes para mudar, rapidamente se tornará difícil de manter, além disso, exigirá o uso de um plugin de expansão de template ( que você deve considerar se tiver vários vimmers em seu projeto).
  • Nem todo mundo usa o vim para se desenvolver. Eu não quero ser incomodado por configurações de editores de outras pessoas, por que eu deveria parasitar deles?
  • É mais fácil pedir que os vimmers instalem um mesmo plugin, em vez de pedir que copiem, colem e mantenham as mesmas linhas em seus arquivos .vimrc.
  • As configurações podem ser salvas com os outros arquivos de projeto (cvs / svn / git / whatever)
  • É realmente fácil ter um arquivo de configuração por projeto – com o plugin, eu tenho um arquivo de configuração global para os padrões de codificação do projeto geral e arquivos de configuração específicos para cada sub-projeto (qual makefile usar, qual executável chamar , …)

BTW, a solução da sth pode ser usada para fornecer um único arquivo de configuração. Isso é muito semelhante à abordagem do plug-in, exceto que o .vimrc deve ser parasitado com opções não globais e não suporta facilmente arquivos de configuração múltiplos / compartilhados.

Você pode colocar algo assim em $VIM/vimrc

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

Eu sugiro fortemente não usar o set exrc

Mesmo com set secure , sob * nix, o vim ainda executará comandos automáticos, shell, e outros, se você possuir o arquivo. Então, se você editar um arquivo naquele tarball, enviei-lhe um .vimrc contendo:

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

Você provavelmente vai se divertir menos do que eu.

Colocar um .vimrc no diretório de trabalho, na verdade, é suportado, somente desabilitado por padrão. Veja :h 'exrc' e :h startup para detalhes, a configuração 'exrc' permitirá a leitura de .vimrc partir do diretório atual.

Também é recomendado :set secure ao usar isso. Isso trava :autocmd , shell e comandos de gravação para .vimrc no diretório atual.

Outra coisa que vale a pena olhar é configurar uma session ( :h session ) com uma visão padrão e configurações para o projeto.

Tudo o que disse, eu provavelmente iria com a opção de plugin detalhada por Luc Hermitte eu mesmo.

Esta questão é antiga, mas parece uma preocupação bastante natural e persistente.

Minha solução é bem simples. Eu coloco um arquivo .vimrc no diretório raiz dos meus projetos. A primeira linha do arquivo .vimrc geralmente .vimrc ~/.vimrc e, em seguida, adiciona a configuração específica que eu quero. Eu alias tvim='vim -u .vimrc' , e uso o tvim em meus diretórios de projetos pessoais. “tvim” para “trusted vim”, o que significa que se eu executá-lo em um diretório com um arquivo .vimrc e algo der errado, não tenho ninguém para culpar além de mim mesmo, já que eu disse explicitamente que confiei nele. Além disso, mantenho um grupo desses armazenados de forma que às vezes posso apenas vincular o que eu quero para um tipo específico de projeto.

Para minimizar os riscos de segurança com QUALQUER recurso “autorun” para QUALQUER COISA nos dias de hoje, posso aconselhá-lo a utilizar os resources existentes do vim em vez de plugins (bagagem de portabilidade)?

Por exemplo.

O arquivo vimrc da minha pasta local é chamado “_gvimrc” (de propósito). Isso reduz a esperança de que pessoas como phen se divertam às nossas custas. 🙂

No meu arquivo $ VIM / .vimrc, eu inseri:

 if filereadable("_gvimrc") source _gvimrc endif 

no fim.

Eu uso “filereadable ()” sobre “fileexists ()” como o mais recente tem alguma estranheza quando torturado com a abertura de vários arquivos (10 +) simultaneamente, (não sei porquê).

É claro, você pode dar seu próprio nome de arquivo exclusivo para ofuscar ainda mais os possíveis causadores de problemas. Tais como “_mygvimrc”, “_gobbledygook”, etc. Você só precisa estabelecer um nome padronizado e fornecê-lo adequadamente em seu $ VIM / .vimrc. Baseando-se em internals vi / vim para isso exclui problemas de portabilidade. MAS, NÃO nomeie-o como .vimrc (ou _vimrc) para evitar o uso recursivo caso você esteja editando o arquivo $ VIM / .vimrc com o vim depois.

Estou usando isso desde o Windoze 98SE, através do Windork XP Pro e agora do Windorkier 7 (5 ou mais anos). Vou marcar uma lista de arquivos .txt no Explorer e depois usar “Editar com vários Vim”, resultando na abertura simultânea de várias janelas vim. Pelo meu trabalho, faço isso várias vezes ao dia, diariamente. Todos os arquivos foram tratados com o que eu configurei no meu _gvimrc local.

Supondo que as pessoas não estejam adicionando arquivos a cada poucos dias, você provavelmente poderá adicionar uma modelagem no topo de cada arquivo. Na verdade, se o seu sistema de version control permitir, você provavelmente aplicaria uma regra que diz que cada arquivo deve ter uma modeline quando é feito check-in.

Concordo com a abordagem do plugin por motivos de segurança.

Existe um plugin muito bom que ainda não foi mencionado. Ele permite que você use um .lvimrc nos diretórios do seu projeto.

Experimente “localvimrc”:

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

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

Experimente o 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

Eu olhei para os plugins que existiam e realmente não gostava de nenhum deles, então eu escrevi uma function simples que o porquinho usa em vim-fugitivo . A vantagem disso é que ele sabe que a raiz do projeto é sempre a raiz do repository e, além disso, posso fazer o hash do arquivo para manter uma tabela de confiança. Basta colocar o seguinte no seu arquivo .vimrc .

 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 ^= ! 

Se o ! a opção está definida na configuração viminfo , então o dictionary SAFE_VIMRC será preservado entre as execuções (observe o ^ para preceder a opção para que não atrapalhe a opção n ).