Now that people set the full Vim settings (from vimrc plus plugins, colors, syntax, etc.) to github, I would like to play with my settings “as is”, so I can see what I could pass to my Vim installation.
===== Current progress == (September 28, 2012) ==================================== =================
I have a solution working for this, it needs to be polished a bit before putting on github, but I wanted to update it to show what I'm doing. I set up a normal .vimrc file to check the user environment variable to determine which repo to start the gvim session. I have other Vim installations for people cloned into a folder named "vimfiles_Sets", each of which is placed in a separate folder with the owner github name (one of these names is what gets into the user environment variable: "vimActiveRepo"). When you create a user environment variable, set it to the repository containing your Vim installation.
There are only two changes for the execution path, the first record is overwritten with the absolute path to the repo, and the last record receives the same treatment with the added “after” folder. This is done in a .vimrc file, which then creates a file based on the vimrc file of the repo owner.
People from linux decided to attach their .vimrc file to a file named vimrc in their repo, I will copy this file to vimrc_toLoad (left without a trace in git), so that you can make the necessary corrections to it without exposing if you update the repo. Sometimes it is necessary to make changes to this file for everything to work, for example. paths to file names, pathogen / vundle calls, etc.
With the "vimActiveRepo" installation installed on your installation (which you put into the git repository and therefore can be easily downloaded to github for sharing), any cmd or gui invocation line will start your normal installation. Since you are unlikely to abandon your installation for someone else, we will never actually change this value. What we do is an application that starts a cmd / shell session, changes the "vimActiveRepo" for that session (that is, overshadows its value inside the session) and starts the Vim repository you want to play with.
I have a python program using wx to provide a drop down list of available repositories with a run selected button to start it.
===== Previous post: =========================================== ============================= I'm halfway through .vimrc, which creates a custom execution path that spans the repo, before finding the vimrc file in a locally cloned repository, but where I think I'm wrong, as far as I can see by looking at: scriptnames, is that ~ .gvimrc gets a call instead of one in the repo. Nowadays, it seems common .gvimrc to “rename” a vimrc file to get gui-based settings that didn't load the first time vimrc was received, since Vim didn't have gui running. This is what I compiled from the search: scriptnames for a typical Vim installation and comparing it with script names: the result from a copy of this installation placed in a repo-like set of directories.
Running Vim 7.3 on Windows 7
.vimrc file:
" change the following line to try out a different vim setup let repo = 1 " Table of values and the repo they will activate " 0 -- the normal home directory based vimrc " 1 -- try John Anderson 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, the further work that just changed ~ / .gvimrc for the gvimrc source in the repository made me get around this, but now it looks like a pathogen, (the most suitable plugin manager) incorrectly modifies the runtimepath to include the bundle / subdirectory stored in the repo.
I will need to debug this and see what needs to be done to fix this.