Variável de ambiente para o caminho do tempo de execução pessoal? (~ / .vim no * nix, ~ / vimfiles no win32)

9

Estou tentando mover meu .viminfoarquivo para minha .vim/pasta para uma sincronização mais limpa em várias máquinas. (Eu tenho meu .vimarmazenado no Dropbox e, em seguida, crio links simbólicos para ele no meu diretório pessoal.)

Então, nesta manhã, encontrei esta resposta sobre como fazer exatamente isso. Ótimo! Infelizmente, eu uso o Windows no trabalho e o Mac em casa, o que ~/.vimacontece algumas vezes ~/vimfiles. Como resultado, uma solução de uma linha

set viminfo+=n~/.vim/viminfo

agora se tornou uma solução de 5 linhas

if has('unix')
  set viminfo+=n~/.vim/viminfo
elseif has('win32')
  set viminfo+=n~/vimfiles/viminfo
endif

o que me parece desajeitado.

Existe algum tipo de variável de ambiente padrão que posso usar para acessar o caminho de tempo de execução específico do usuário, à la $VIMRUNTIMEou $MYVIMRC? Ou isso é algo que eu só tenho que dançar?

vimrc

— Ryan Lue
fonte

8

Isso deve funcionar e é independente da plataforma / plugin: fnamemodify(expand("$MYVIMRC"), ":p:h")

— poppyschmo
fonte

Vocês são gênios.

— Ryan Lue

5

Supondo que você não o tenha alterado, o primeiro item em &runtimepathé seu diretório de tempo de execução por padrão:

$HOME/.vim        on unix-like systems
$HOME\vimfiles    on windows

Você pode usar esse valor para informar ao Vim onde colocar seu viminfoarquivo com este liner independente de plataforma:

let &viminfo .= ',n' . split(&rtp, ',')[0] . '/viminfo'

Recursos:

:h :let-option
:h split()
:h runtimepath

— romainl
fonte

Infelizmente isso não é verdade. &runtimepathé manipulado pelos gerenciadores de plugins, não há absolutamente nenhuma razão para começar com $HOME/.vimou com $HOME\vimfiles.

— Lcd047

@ lcd047, em seu estado padrão, &runtimepathsempre inicie com o diretório de tempo de execução padrão no nível de usuário da plataforma atual. Agora, é obviamente possível que o usuário 'rtp'destrua seu reconhecimento irreconhecível, mas o patógeno, vundle, plug, VAM e neobundle do AFAIK todos partem ~/.vim(ou similares) no início.

— romainl

Somente com a configuração padrão. Por um longo tempo, usei algo como isto pathogen#infect("$VIM/local/bundle/{}"):, para permitir (1) ter pacotes disponíveis para todos os usuários, (2) mantê-los separados do tempo de execução principal do Vim e (3) permitir que eu os atualize automaticamente. ~/.vimacaba no meio do grupo com essa configuração.

— Lcd047

@ lcd047, mudei a redação da primeira frase de acordo com nossa conversa.

— romainl

Fiz isso por mim e me parece a solução mais elegante, dada a minha configuração. Obrigado!!

— precisa

2

O primeiro erro que vejo repetidamente em relação ao Windows é sempre tentar resolver o problema usando $HOME, não.

O uso $HOMEacabará causando problemas, especialmente se você usar qualquer ambiente semelhante ao Unix (Cygwin, git bash, etc.). Não o use em scripts, não o defina como uma variável de ambiente. De fato, a configuração $HOMEfará com que o Cygwin pare de funcionar corretamente e o git bash faça o mesmo. Quanto mais você brinca com $HOMEos piores, os bugs ficam mais difíceis. Só não use.

O Windows constrói $HOMErapidamente e nos bastidores com %HOMEDRIVE%%HOMEPATH%. Basta usar isso dentro de seu ( _vimrcou vimrcsem ponto):

set viminfo+=n%HOMEDRIVE%/%HOMEPATH%/vimfiles/viminfo

Isso deve resolver o problema. Se você mudou vimfilespara .vimajustar em conformidade.

— user1640896
fonte

0

O que fiz foi renomear a pasta viminfo do Windows para .vim (ou copiar o conteúdo do primeiro para o último e depois excluí-lo) e vinculá-lo novamente mklink /d viminfo .vim. (Observe que o mklink leva seus argumentos na ordem oposta ao comando ln do Unix.)

— Edward
fonte