vim – pathogen i github

Ostatnio straciłem w głupi sposób moją konfigurację Vim’a (a właściwie folder .vim – plik .vimrc został… tak btw dzięki metodzie opisanej w niniejszym artykule, ale nie tak sprytnej aby zrobić backup wszystkiego co może dotyczyć vim’a), więc zmuszony byłem skonfigurować sobie wszystko jeszcze raz. I tym razem zrobię to mądrzej. Po pierwsze dlatego, że łatwo będę mogł zrobić backup CAŁEJ konfiguracji vim’a. Po drugie dlatego, że skorzystam z pluginu Pathogen, który pozwala na fantastyczne zarządzać zainstalowanymi pluginami. I chyba troche po trzecie dlatego, że wreszcie wybrałem z większą uwagą pluginy.

Jak działa Pathogen? Zamiast instalować pluginy bezpośrednio do folderu .vim (strasznie duży bałagan i ogromne trudności z ogarnięciem tego później, np. usunięciem jednego pluginu) instalujemy je do folderu .vim/bundle/jakas_nazwa, a Pathogen zajmuje się tym żeby dla Vim’a były widoczne tak jak gdyby zostały zainstalowane w tradycyjny sposób. Co musimy zrobić? Kopie zapasowe plików konfiguracyjnych, a potem możemy utworzyć świeżą konfigurację:

cd $HOME
mv .vimrc vimrc-backup
mv .vim vim-backup
mkdir -p .vim
touch .vim/vimrc
ln -s .vim/vimrc .vimrc
mkdir -p .vim/bundle
mkdir -p .vim/autoload
cp /path/to/pathogen/pathogen.vim .vim/autoload
git init .vim
vim .vimrc

Do edytowanego pliku dodajemy:

set nocompatibile
filetype off
call pathogen#runtime_append_all_bundles()
call pathogen#helptags()
filetype plugin indent on

i zapisujemy plik. W tej chwili mamy już gotową strukturę katalogów i plik .vimrc przygotowany do poradzenia sobie z Pathogenem. Musimy jedynie dodać nasze pluginy i wyedytować .vimrc tak, aby odpowiadało naszym potrzebom (przykład będzie później).

Zajmijmy się teraz pluginami. Każdy plugin ma swój folder w $HOME/.vim/bundle. Pluginy do Vima możemy mieć ściągnięte w trzech “postaciach”:

1. plik *.vim
2. plik spakowany (np. zip, tgz, tbz2, etc.)
3. plik *.vba

I w każdym przypadku inaczej wygląda (z punktu widzenia użytkownika) instalacja. Pokrótce omówię, uwzględniając różnie wynikające z używania przez nas Pathogen’a, jak je zainstalować.

1. Plik *.vim jest kopiowany do odpowiedniego folderu – zwykle jest to autoload, ftplugin lub plugin w $HOME/.vim. Zmiana przy użyciu pathogen’a jest banalna – plik kopiujemy do folderu autoload, ftplugin lub plugin (w zależności od instrukcji twórcy/czyni) w folderze $HOME/.vim/bundle/nazwa_pluginu.
2. W tym wypadku rozpakowywaliśmy plik odpowiednim poleceniem w folderze $HOME/.vim – w spakowanym pliku zawsze (a przynajmniej ja nie zetknąłem się z sytuacją żeby tak nie było) zachowana była odpowiednia struktura folderów, więc to co miało iść np. do plugin szło do plugin, a to co miało iść do doc szło do doc. Teraz rozpakowujemy plik w folderze $HOME/.vim/bundle/nazwa_pluginu.
3. Tu zmiana jest największa – do tej pory plik vba otwieraliśmy w Vimie i wydawaliśmy polecenie :so %, teraz natomiast wydajemy polecenie :UseVimball ~/.vim/bundle/nazwa_pluginu. Pamiętajmy tylko aby stworzyć ten folder wcześniej, bo inaczej Vimball się wykrzaczy (ponoć, tak przeczytałem gdzieś, samemu nie chciało mi się testować).

No i to wszystko, mamy ładnie zainstalowane pluginy w osobnych folderach, więc łatwo sprawdzić czy jakiś już jest zainstalowany, usunąć, dodać nowe.

Ja natrafiłem na mały problem z pluginem C: przy włączeniu Vima dostawałem komunikat “Local template ‘/home/qba/.vim/c-support/templates/Templates’ file not readable.” Łopatologicznie można go rozwiązać bardzo łatwo. Otwieramy w Vimie plik $HOME/.vim/bundle/c/plugin/c.vim i zamieniamy dwie linie:
let s:C_LocalTemplateFile = $HOME.'/.vim/c-support/templates/Templates'
(...)
let s:C_CodeSnippets = $HOME.'/.vim/c-support/codesnippets/'
na
let s:C_LocalTemplateFile = $HOME.'/.vim/bundle/c/c-support/templates/Templates'
(...)
let s:C_CodeSnippets = $HOME.'/.vim/bundle/c/c-support/codesnippets/'
Nie jest to może najbardziej eleganckie rozwiązanie, ale coż… działa.

Teraz sprawa z gitem… dlaczego na początku wśród wydanych komend znajdowało się “git init .vim”? Otóż korzystając z gita możemy bardzo łatwo zrobić sobie kopię zapasową naszej konfiguracji Vim’a. W razie gdybyśmy ją stracili możemy ją sobie później pobrać. Do tego dochodzi kilka możliwości takich jak powrót do wcześniejszych wersji naszych plików, możliwość forkowania, etc… ale to trzeba poczytać trochę o możliwościach Git’a.
Zakładamy więc sobie konto na www.github.com, a następnie tworzymy nowe repozytorium o nazwie np. vim. A potem zgodnie z instrukcjami (bez [*]):
git add autoload/* bundle/* vimrc [1]
git commit -m 'first commit' [2]
git remote add origin git@github.com:twoj_login/vim.git [3]
git push origin master [4]
[1] Tu dodajemy do repozytorium pliki: vimrc i wszystkie z folderów autoload i bundle. Moglibyśmy zrobić “git add *”, ale wtedy dodałyby się również pliki z folderu view oraz pliki *.swp, co jest zdecydowanie niepożądane. Wyjściem bardziej eleganckim jest wpisanie w pliku $HOME/.vim/.git/gitignore reguł dla ignorowanych plików:
*.swp
view/*
To powinno wystarczyć, choć nie testowałem, moja wiedza jest teoretyczna i może być różnie. Po wydaniu tych komend będziecie mieli repozytorium z Waszą konfiguracją Vim’a na Githubie. Gdy dokonacie edycji pliku wydajecie polecenia [1] (w zasadzie dla pliku, który został wyedytowany, ale można też dodać jeszcze raz wszystkie) i [2], a gdy będziecie mieli ochotę żeby uaktualnić Wasze repozytorium na Githubie to [4]. Jeśli stracicie z jakiegoś powodu folder .vim to łatwo go odzyskać:
cd $HOME
git clone git@github.com:twoj_login/vim.git
mv vim .vim
Git zapisze pobrane pliki w folderze takim, jak nazwa pobieranego repozytorium, więc musimy zmienić jego nazwę z vim na .vim… i już! A potem tylko git add, git commit, git push. :)

Jako, że jestem fanem podejścia “jeden post – jeden temat” i nie lubię postów w stylu “co mi do głowy przyszło” to na tym zakończę. Tak na prawdę w tym opisałem dwie sprawy, ale już na to przymknę oko. Wiem, że brakuje czegoś o pluginach i pliku .vimrc. Będzie w kolejnych. Nie wiem kiedy.

A jeśli ktoś nie umie korzystać z Googli to tu jest link do Pathogen’a.