Pseudo-tutorial do Vima

Nareszcie jest długo wyczekiwane (jasne...) obiecane przeze mnie wprowadzenie do Vima. Miałem dość dużo na głowie, stąd aż trzy miesiące oczekiwania.

Na początek wyjaśniam, czym ten wpis NIE jest: - spisem poleceń (jakby mało ich było w necie...), - samowystarczalnym kursem Vima - chcę raczej uzupełnić lukę w innych kursach, - czymś, co zrobi z czytelnika vimiatacza w 20 minut.

A czym jest? Opisem filozofii działania Vima i opisem często ignorowanych, a przydatnych poleceń. Nie radzę kontynuować bez zaliczonego vimtutora lub znajomości podstaw. Możliwe, że część informacji się powtórzy, bo nie pamiętam już, co tam było, ale nie zamierzam wykładać najpodstawsiejszych podstaw. Bardzo możliwe, że tempo będzie nieco zbyt szybkie. W razie czego, polecam po każdym większym fragmencie potestować omawiane polecenia. Bądź co bądź, to mój pierwszy wpis tego typu, więc na pewno coś spaprałem. Ostrzegam, może być nudno. Opinie mile widziane. ;)

Poruszanie się

Może się wydawać, że poruszanie się jest na tyle prostą czynnością, że można ograniczyć się do podstawowych przycisków. Ja się z tym absolutnie nie zgadzam. To tutaj Vim NISZCZY inne edytory. Przydatne sposoby przemieszczania się:

Przejście do znaku

`f` i `t` czyli "find" i "till" pozwalają przesunąć się do najbliższego wystąpienia znaku, który wciśniemy po `f` lub `t`. Przykład: Mamy zdanie "Nie mam pomysłu na przykład". Mamy kursor na literze 'a' w słowie "mam". Wciskamy `fy` i lądujemy na literze 'y' w słowie "pomysłu". Te dwa polecenia różnią się tym, że `t` zostawia nas tuż przed tym znakiem, a `f` już na nim. W powyższym przykładzie `ty` zostawiłoby nas na 'm', nie 'y'. Nie jest to aż tak użyteczne przy samym poruszaniu się, ale przyda się nam w dalszej części tego wpisu.

Przejście do wybranej linii

`G` - przeniesienie się do ostatniej linii. Gdy poprzedzimy je jakąś liczbą, przenosi nas do linii o tym numerze. To drugie jest bardzo przydatne np. przy szukaniu błędów wyplutych przez kompilator.

Nawigacja wg ułożenia tekstu

`gj`/`gk`/`gh`/`gl` są bardzo wygodne w dość specyficznych sytuacjach. Rozważmy następującą sytuację: mamy dłuuuugą linijkę, którą Vim nam zawinął. Chcemy przenieść się z jej górnej części do dolnej, więc wciskamy `j`. Okazuje się, że Vim przeniósł nas o dwie linijki. Czemu tak się stało? Dla niego to dalej była ta sama linia, mimo że rozbita na dwie. Poprzedzając klawisz ruchu literą `g` wymuszamy na Vimie orientację wg ułożenia linii. Rzadko wykorzystywane, ale dobrze znać.

Skoki

Ctrl-O/Ctrl-I, czyli cofanie i powtarzanie "skoków". Najpierw zdefiniujmy sobie, czym jest skok. W momencie, gdy przenosimy się o wiele linii np. przez 'G' lub podczas wyszukiwania, wtedy właśnie wykonujemy skok z miejsca, gdzie jesteśmy do punktu docelowego. Ctrl-O pozwala nam skoczyć do tyłu. Jesteśmy przykładowo w 135. linijce i wywołujemy `15G`, przenosimy się do linijki nr 15. Teraz wciskamy Ctrl-O i znowu lądujemy w linijce nr 135. Ctrl-I robi to samo, ale w drugą stronę. Można na to patrzeć jak na przyciski "wstecz" i "dalej" w przeglądarce.

Uzbrojeni w nowo zdobytą wiedzę, możemy bezpiecznie przejść dalej.

Typy poleceń

Polecenia w Vimie podzielimy sobie na dwa typy. Pierwsze to polecenia zwykłe, wprowadzane w trybie normalnym. Drugie to komendy wpisywane w trybie Ex (to ten uruchamiany dwukropkiem).

Polecenia normalne

Najpierw przyjrzyjmy się pierwszej grupie. Ogólny schemat tych poleceń wygląda tak: [polecenie][przesunięcie]. "Polecenie" to np. `d`, `c` czy `=`. Ogólnie, tutaj mówimy, co chcemy zrobić. Mała uwaga - to nie musi być jeden znak (np. `g?` pozwala potraktować tekst algorytmem pseudo-szyfrującym ROT13). "Przesunięcie". Tutaj zaczyna się część, którą wielu użytkowników Vima ignoruje i używa trybu wizualnego zamiast niej (to ten do zaznaczania). Moim zdaniem, tryb wizualny jest zrobiony na siłę i nie pasuje do filozofii Vima. Nie bez powodu Vi, pierwowzór Vima, go nie miał. Wracając do tematu, tym parametrem wskazujemy, na jakim obszarze chcemy działać wybraną komendą. Przykładowo `dj` czytamy tak: "kasuj od tej linijki do następnej". W efekcie kasujemy dwie linijki. `d2j` skasowałoby trzy. Często jest też tak, że gdy wciśniemy dany klawisz dwa razy, to polecenie działa w obrębie obecnej linii (np. `dd`).

Teraz czas na kilka bardziej złożonych przykładów. Jak już wspomniałem, `g?` "szyfruje" tekst. Wpisujemy `ggg?G`. Zanim przeczytacie, co to zrobi, proponuję samodzielnie się chwilę zastanowić. Już? No to lecimy. Najpierw przenosimy się na początek pliku (`gg`). Potem chcemy od tego punktu "zaszyfrować" tekst (`g?`). A dokąd? Do końca pliku (`G`).

Inny przykład. Mamy następującą deklarację funkcji w C/C++:

int fun(double arg1, char* arg2);

Stoimy na przecinku za "arg1". Stwierdzamy, że drugi parametr jednak nie jest nam potrzebny, więc chcemy go usunąć. Wpisujemy `dt)`. Kasujemy wszystko od tego punktu (od przecinka), aż do nawiasu zamykającego (z jego wyłączeniem). Gdyby był jeszcze arg3, który chcemy zostawić, możemy skasować wszystko do następnego przecinka (`dt,`). Takie myślenie wymaga przyzwyczajenia się, ale bardzo ułatwia życie.

Polecenia Ex

Jakby się ktoś zastanawiał skąd taka nazwa, Ex to nazwa edytora, który pracuje jedynie w takim trybie, jaki serwuje nam Vim po wciśnięciu dwukropka.

Te polecenia mają przeważnie taką składnię: :[zakres][polecenie], przy czym zakres jest przeważnie opcjonalny.

Zakresem mogą być na przykład numery dwóch linii oddzielone przecinkiem. Bardzo często wykorzystuje się zakres '<,'>. Apostrof odwołuje się do linii zawierającej pewien znacznik (mark). Mark to jakiś punkt w tekście, do którego można się odwołać właśnie używając znaku `'`. Nie będę się teraz zagłębiał w to, jak się je tworzy, bo sam tego niemal nie robię. Ważne jest to, że Vim posiada wiele znaczników automatycznych. < i > oznaczają początek i koniec zaznaczenia. Ten zakres jest automatycznie wybierany, gdy wchodzimy do trybu Ex z trybu wizualnego. Drugim ważnym zakresem jest % - cały plik. Jeśli nie podamy zakresu, to przeważnie pracujemy na pojedynczej linii.

Przykład zastosowania zakresów: `:10,20w file2'. To polecenie zapisze linie od 10 do 20 w pliku "file2".

Nieco bardziej złożonym przypadkiem są komendy `:g` i `:s` (i pewnie jeszcze jakieś, o których zapomniałem). Ta pierwsza pozwala wykonać jakieś inne polecenie jedynie na liniach spełniających podane wyrażenie regularne. Składnia wygląda tak: :[zakres]g/RegEx/polecenie. W tym przypadku domyślny zakres to %. Np. `:g/.*doskasowania.*/d` skasuje nam wszystkie linie zawierające słowo "doskasowania". Tak naprawdę, mogłem tu opuścić ".*", ale zostawiłem dla jasności, że to RegEx. `:s` pozwala nam zamieniać jakieś wyrażenia na inne. Składnia: :[zakres]s/CoZamieniamy/NaCo/flagi. Np. `%s/foo/bar/g` zamieni wszystkie wystąpienia słowa "foo" na "bar". Przydatne flagi: 'g' - zamieniaj wszystkie wystąpienia w jednej linii, nie tylko pierwsze; 'c' - proś o potwierdzenie; 'i' - nie zwracaj uwagi na wielkość liter.

Co ciekawe, można łączyć te dwie komendy: `:g/foo/s/bar/baz/`. To polecenie zamieni w każdej linijce zawierającej słowo "foo" słowo "bar" na "baz".

Aktualizacja: W komentarzu robert-km przypomniał mi o `:v` czyli odwrotności `:g` - wykonuje operacje na liniach nie pasujących do RegEksa..

Jak NIE używać Vima

Wiele osób zarzuca Vimowi, że nigdy nie wiedzą, w jakim trybie są. Ten problem można bardzo łatwo wyeliminować. Wszystkie tryby poza normalnym powinniśmy traktować jako tymczasowe - wskakujemy do trybu pisania, piszemy, co chcemy i wracamy do normalnego. Wtedy nie będzie wątpliwości, w jakim trybie jesteśmy - o ile czegoś nie robimy, jesteśmy zawsze w normalnym. A gdy coś robimy, raczej o tym wiemy. ;)

Znam kilka osób, które wolą przebywać w trybie pisania praktycznie cały czas. Oni tak naprawdę nie zyskują nic na używaniu Vima - dalej obsługują go jak każdy inny edytor. Powiedziałbym nawet, że lepiej by im się pracowało w klasycznym edytorze - Vim nie jest do takiej pracy przystosowany. Jeśli chcecie wycisnąć z Vima jak najwięcej, spróbujcie zerwać z nawykami.

Skoro już przy nawykach jesteśmy, nie polecam korzystania z menu, które oferuje gVim (wersja Vima z interface'em opartym na GTK). Można coś tam czasem podejrzeć, ale nie o menu chodzi w Vimie. Osobiście korzystam z w pełni tekstowej wersji Vima, więc mnie nawet nie kusi.

Tutaj już wyjdę trochę poza tematykę samego Vima. Część użytkowników Vima zwalcza użytkowników innego nietypowego edytora - Emacsa. Moim zdaniem oba te edytory świetnie współgrają i nie ma sensu się kłócić, który jest lepszy. Emacs ma przykładowo świetną interakcję z zewnętrznymi programami (debuggery czy inne dziwactwa). Zamiast prowadzić wojny o jedyny słuszny edytor, lepiej dobierać je odpowiednio do tego, co robimy. Do tematu Emacsa prawdopodobnie jeszcze wrócę na tym słit blogasku, ale to nie temat na teraz.

Niby oczywista oczywistość, ale warto wspomnieć - to, że się zacznie używać Vima, nie sprawi, że będzie się lepszym programistą, a osoba, która go nie używa może "kodzić" tak samo dobrze. To jednak jedynie narzędzie. Wiele ułatwiające, ale narzędzie. Piszę to, bo niektórzy zdają się o tym zapominać.

Zakończenie

Oczywiście ja zaledwie musnąłem temat Vima, ale to powinno wystarczyć jako solidne podstawy. Taką przynajmniej mam nadzieję - jak już wspomniałem na początku, to mój pierwszy tego typu tekst. Jeśli chodzi o dalszą naukę, nie ma sensu szukać jakichś cudownych tutoriali - trzeba po prostu używać.