O tym, jak vimiarz przeszedł na Emacsa

W poprzednim wpisie wspominałem, że będzie jeszcze coś o Emacsie. No to jest. Dość niespodziewany zwrot akcji, nawet dla mnie.

Myśl o poznaniu Emacsa chodziła mi po głowie już od wielu miesięcy. Jakieś podstawy znałem, ale niewiele ponad to. Co mnie skłoniło do przejścia do "obozu wroga" i jakie są moje przemyślenia?

Potrzeba rozwoju

Wiem, że brzmi to jak jakiś nonsens, ale jednym z moich większych problemów stała się przesadna znajomość Vima. Oczywiście nie wiem WSZYSTKIEGO, ale coraz rzadziej odkrywałem w nim coś nowego. Czułem, że potrzebuję nowego wyzwania. Jak się potem okazało, to wyzwanie mnie przytrzymało na dłużej.

Interakcja z zewnętrznymi procesami

Jedną z największych bolączek Vima jest brak możliwości interakcji z zewnętrznymi procesami bez dużego kombinowania. Najbardziej widać to, gdy trzeba debuggować jakiś program. Niby jest projekt Clewn, ale nigdy nie udało mi się go zmusić do działania. W Emacsie po prostu włączam M‑x gdb i debugguję jakby nigdy nic. Jak jeszcze dodam potem M‑x gdb‑many-windows, to zaczynam się zastanawiać po co są nakładki w stylu ddd (które mi jakoś w ogóle nie podchodzi). Przyznam się, że większą przygodę z Emacsem zacząłem właśnie od debuggowania. Najpierw szukałem błędów Emacsem, a naprawiałem Vimem, potem już mi się nie chciało skakać po oknach i naprawiałem już w Emacsie, a na końcu prewencyjnie włączałem Emacsa "bo może będę debuggował".

Wewnętrzny język skryptowy

Na początku wyjaśnijmy sobie jedną rzecz. Vimscript nadaje się świetnie do torturowania wrogów i chyba tylko do tego. Proste rzeczy można w nim zrobić, ale przy bardziej zaawansowanych zadaniach czuć, że ten język był tworzony na przestrzeni wielu lat i dopiero niedawno stał się czymś bardziej rozbudowanym. Z kolei Elisp używany w Emacsie jest jednym z dialektów poważnego języka jakim jest Lisp. Składnia jest trochę nietypowa, ale można się przyzwyczaić i ma ona swój urok. Używanie Lispa jako główny język edytora ma jeszcze tę zaletę, że kod lispowy można wsadzić niemal wszędzie - w szablon, w wartość zmiennej konfiguracyjnej, podobno nawet w RegEx. Jako bonus, konfigurując Emacsa uczymy się języka, który być może przyda nam się kiedyś w naszym życiu zawodowym. W Vimscripcie się raczej nie pisze poza Vimem. :P

Uczucie "zaplanowania" W Emacsie aż czuć, że to wszystko zostało dokładnie przemyślane. Po prostu wszystko do siebie pasuje. Ciężko mi to bardziej opisać. Emacs był od razu planowany jako rozbudowany edytor. Vi, pradziad Vima, był prostym edytorem z nietypowym obłożeniem klawiszy. Przykładem znacznie lepiej przemyślanej funkcji jest wprowadzanie ścieżek - Emacs obsługuje tzw. fuzzy matching jeszcze lepiej niż zsh, z którego to znam. O co chodzi? Wpisuję "~/p/c+/i/sr" i wciskam Tab. Tekst zamienia się w "~/programs/c++/integral/src". Vim obsługuje jedynie standardowe uzupełnianie Tabem bez udziwnień. Niby nic, ale ja z tego korzystam prawie cały czas. Wiem, że Emacs i Vi są w podobnym wieku, ale Emacs sprawia wrażenie znacznie dojrzalszego.

Emacs Daemon

A to, to jest po prostu poezja! Włączam sobie na starcie systemu daemona, a potem każdy kolejny Emacs pracuje na współdzielonych buforach, ustawieniach, wszystkim. Dodatkowo, kolejne Emacsy włączają mi się błyskawicznie (no dobra, to był główny cel, gdy to pisali...) . Vim niby ma jakąś szczątkową obsługę pracy w trybie klient-serwer, ale zawsze mi się wydawało, że to działa na zasadzie "Ej, Heniek! Rąbnijmy tutaj serwera! Może się przyda!".

Zarządzanie wieloma plikami/buforami W Vimie zawsze irytowało mnie zarządzanie buforami. Domyślnie sam zamykał więcej niż trzeba, za to po włączeniu opcji "hidden" (która w teorii sprawia, że Vim sam nic nie zamyka), działy się czasem dziwne rzeczy. Emacs z założenia nie zamyka nic o ile mu tego wyraźnie nie rozkaże. Przy takich założeniach, musi mieć dobre zarządzanie buforami i na szczęście faktycznie ma.

Problemy

Nie da się ukryć, że Vim ma jednak kilka asów w rękawie.

Uzupełnianie składni

W Emacsie bardzo brakuje mi vimowego Omnicompletion. Podobno da się zrobić jakieś dopełnianie składni. Podobno. Próbowałem już kilku wtyczek i żadna nie zdała egzaminu. CEDET, który wydawał mi się rozwiązaniem, nawet nie chciał się zainstalować.

Inna filozofia

Sporym problemem jest mój styl pracy. Do tej pory wiele robiłem w shellu. Wchodziłem do katalogu, włączałem Vima, pisałem coś, zrzucałem do tła, robiłem coś, itd. Miałem sporo autorskich ułatwień, przez co pracowało mi się naprawdę wygodnie. Emacs kładzie nacisk na robienie wszystkiego z poziomu samego edytora. Niby jest nieźle, ale np. Gita wolę obsługiwać klasycznie. Częściowo udało mi się coś na to zaradzić i zmapowałem sobie jakiś klawisz do uruchamiania xterma (wbudowane w Emacsa emulatory terminali miały problemy z moim wypasionym promptem). Mimo wszystko, wywrócenie stylu pracy do góry nogami trochę boli.

Podświetlanie nie‑kodu Apropos Gita. Vim mi bardzo ładnie podświetlał wszelkie jego pliki tymczasowe np. przy robieniu commita czy interaktywnego rebase'a. Emacs serwuje mi zwykły biały tekst. Ogólnie, Vim znacznie lepiej podświetla zwykłe "generic" pliki konfiguracyjne. Jako ciekawostkę dodam, że Vim podświetla config Emacsa (nie wiem czy nie lepiej niż sam Emacs!), ale w drugą stronę jest już cienko.

Zwijanie tekstu

Boli mnie też brak vimowego zwijania tekstu. Stawiałem gdzieś parę znaczników "{{{" i "}}}" i gotowe. W Emacsie znów podobno coś takiego jest.

Uniwersalność

Tu będzie krótko: nawet mój router ma Vi, czego o Emacsie powiedzieć nie mogę.

Podsumowanie

Wszystko wskazuje na to, że do większości zadań zostanę przy Emacsie. Nie zmienia to jednak faktu, że Vim to wciąż świetny edytor i nadal będę go do pewnych rzeczy używał.

PS: Tak, wiem, że w necie są dosłownie setki podobnych wpisów (z przejściami w obie strony).