开发者

A way to try out different peoples github Vim setups

开发者 https://www.devze.com 2023-03-26 19:03 出处:网络
Now that people are putting complete Vim setups, (of vimrc plus plugins, colors, syntax, etc), up on github, I\'d like a way to play with their setups, \"as is\", so I can see what I might like to tra

Now that people are putting complete Vim setups, (of vimrc plus plugins, colors, syntax, etc), up on github, I'd like a way to play with their setups, "as is", so I can see what I might like to transfer over into my Vim setup.

=====Current progress==(Sep. 28, 2012)===================================================

I've got a solution working for this, it needs some more polish before putting on github, but I wanted to update this to show what I'm doing. I've made the normal .vimrc file check a user environment variable to determine what repo to start a gvim session on. I've got other peoples Vim installations cloned into a folder named 'vimfiles_Sets', each placed into a separate folder named with the owner's github name, (one of those names is what ends up in the user environment variable: 'vimActiveRepo'). When you create the user environment variable, set it to the repo containing your Vim installation.

There are only two changes needed to the runtimepath, the first entry is overwritten with the absolute path to the repo, and the last entry gets the same treatment with an 'after' folder added. This is done in the .vimrc file, which then sources a file based on the repo's owner vimrc file.

People on linux have taken to symlinking their .vimrc file to a file named vimrc in their repo, I copy that file to vimrc_toLoad, (left untracked in git), so you can make any needed adjustments to it without subjecting it to being clobbered should you update the repo. Sometimes adjustments need to be made to this file to make everything work, e.g. filename paths, pathogen/vundle calls, etc..

With 'vimActiveRepo' set to your installation, (which you make into a git repo and thus can easily upload to github to share), any cmd line or gui invocation will start up your normal installation. Since you're unlikely to abandon your installation for someone else's, we actually never change this value. What we do is have an application that starts a cmd/shell session, changes 'vimActiveRepo' for that session, (i.e. overshadows its value inside of the session), and starts the Vim repo you want to play with.

I've got a python program using wx to provide a dropdown list of the available repos with a 'run selected' button to start it.

=====Older post:===================================================================== I'm halfway there with a .vimrc that builds a custom runtimepath spanning the repo before sourcing the vimrc file in the locally cloned repository, but where I think I'm going wrong, as far as I can figure out by looking at :scriptnames, is that ~.gvimrc is getting called instead of one in the repo. It seems common these days to have .gvimrc "re-source" the vimrc file to pick up gui based settings that did not load the first time vimrc was sourced as Vim did not have the gui running. This is what I gathered from looking :scriptnames for a normal Vim setup, and comparing it to the :scriptnames result from a copy of that setup placed in a repo-like set of directories.

Running Vim 7.3 on Windows 7

the ~.vimrc file:

    " change the following line to try out a different v开发者_如何学Pythonim setup
let repo = 1
" Table of values and the repo they will activate
"   0 -- the normal home directory based vimrc
"   1 -- try John Anderson's setup
"   9 -- run a copy of the home directoy based vim from eleswhere


if repo == 0
  source ~/.vimrc_trf
elseif repo == 1
    set runtimepath=C:\VC\Git\vimfiles_ja\vimfiles
    set runtimepath+=$VIM/vimfiles
    set runtimepath+=$VIMRUNTIME
    set runtimepath+=$VIM/vimfiles/after
    set runtimepath+=C:\VC\Git\vimfiles_ja\vimfiles\after
    source C:\VC\Git\vimfiles_ja\vimfiles\vimrc
    echo 'Hi there, running out of _ja'
elseif repo == 9
    set runtimepath=C:\VC\Misc\vimfiles_trf\vimfiles
    set runtimepath+=$VIM/vimfiles
    set runtimepath+=$VIMRUNTIME
    set runtimepath+=$VIM/vimfiles/after
    set runtimepath+=C:\VC\Misc\vimfiles_trf\vimfiles\after
    source C:\VC\Misc\vimfiles_trf\vimfiles\vimrc
    echo 'Hi there, running out of _trf'
endif

Any thoughts?

Tom

Well, further work that just modified ~/.gvimrc to source the gvimrc in the repository has gotten me around this, but it is now looking like pathogen, (the plugin manager that seems most used), does not correctly change the runtimepath to include the bundle/ subdirectory stored in the repo.

I'm going to have to debug this and see what needs to by done to fix that.


How about creating a repo (in your favorite DVCS) and using branches? Then you can checkout whichever branch you'd like to try. You can also use git-submodules if you're cloning from github to maintain both repos as is. Just a thought.


If your on unix you might want to take a look at vim switcher, it uses symlinks to switch between vimfiles directories.

0

精彩评论

暂无评论...
验证码 换一张
取 消