Теперь, когда люди ставят полные настройки Vim (из vimrc плюс плагины, цвета, синтаксис и т. Д.) На github, я бы хотел поиграть с их настройками "как есть", чтобы я мог видетьто, что я мог бы перенести в настройки Vim.
===== Текущий прогресс == (28 сентября 2012 г.) ===================================================
У меня есть решение, работающее для этогоМне нужно немного отполировать перед установкой github, но я хотел обновить это, чтобы показать, что я делаю.Я заставил обычный файл .vimrc проверять переменную среды пользователя, чтобы определить, в каком репозитории начать сеанс gvim.У меня есть инсталляции Vim других людей, клонированные в папку с именем 'vimfiles_Sets', каждая из которых помещена в отдельную папку с именем владельца github (одно из этих имен - то, что заканчивается в переменной пользовательской среды: 'vimActiveRepo').Когда вы создаете переменную среды пользователя, установите для нее репозиторий, содержащий вашу установку Vim.
Требуется только два изменения пути выполнения, первая запись перезаписывается абсолютным путем к репо, а последняя запись получает ту же обработку с добавленной папкой after.Это делается в файле .vimrc, который затем создает файл на основе файла vimrc владельца репо.
Люди в linux взяли на себя символическую ссылку своего файла .vimrc на файл с именем vimrc в своем репо, я копируюэтот файл vimrc_toLoad (оставлен без отслеживания в git), так что вы можете внести в него любые необходимые изменения, не подвергая его засорению, если вы обновите репозиторий.Иногда необходимо внести коррективы в этот файл, чтобы все работало, например, пути к именам файлов, вызовы pathogen / vundle и т. Д.
с установкой vimActiveRepo в вашу установку (которую вы делаете в git-репо иТаким образом, вы можете легко загрузить на GitHub, чтобы поделиться), любая команда CMD или вызов GUI запустит вашу нормальную установку.Поскольку вы вряд ли откажетесь от установки для кого-то другого, мы фактически никогда не меняем это значение.У нас есть приложение, которое запускает сеанс cmd / shell, изменяет vimActiveRepo для этого сеанса (т.е. затеняет его значение внутри сеанса) и запускает репозиторий Vim, с которым вы хотите играть.
У меня есть программа на Python, использующая wx для предоставления выпадающего списка доступных репозиториев с кнопкой «Run selected», чтобы запустить его.
===== Предыдущая публикация: ===================================================================== Я на полпути с .vimrc, который создает пользовательский путь выполнения, охватывающий репо, прежде чем искать файл vimrc в локально клонированном репозитории, но там, где я думаю, что идет не такнасколько я могу понять, посмотрев: scriptnames, это то, что ~ .gvimrc вызывается вместо одного в репо.В наши дни кажется, что .gvimrc «повторно использует» файл vimrc для выбора настроек на основе графического интерфейса, которые не загружались при первой загрузке vimrc, так как Vim не запускал графический интерфейс.Это то, что я собрал, посмотрев: scriptnames для обычной установки Vim и сравнив его с: scriptnames, из копии этой установки, помещенной в набор каталогов, похожий на репозиторий.
Запуск Vim 7.3 в Windows7
файл ~ .vimrc:
" 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'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
Есть мысли?
Том
Что ж, дальнейшая работа, которая только что изменила ~ / .gvimrc дляИсточник: gvimrc в репозитории заставил меня обойти это, но теперь он выглядит как pathogen (менеджер плагинов, который кажется наиболее используемым), неправильно изменяет путь выполнения, чтобы включить подкаталог / подкаталог, хранящийся в репозитории.
Мне нужно отладить это и посмотреть, что нужно сделать, чтобы это исправить.