Temná strana síly

Již několikrát jsem konstatoval, že ve svaté válce editorů stojím jednoznačně na straně vi a jeho klonů, ale neškodí poznat nepřítele víc do hloubky. Protentokrát však odložíme retardovanou válečnickou rétoriku a podíváme se prastarý kus SW jménem Emacs a jeho klony. Neboť každý SW má své silné a slabé stránky

Neboť každý SW má své silné a slabé stránky a v podstatě jde o to, jak zapadne do toho, čemu se hezky česky říká pracovní workflow.

Emacs

Nebudu opakovat vše, co se o Emacsu lze dozvědět jinde, např. že jde o OS bez slušného editoru apod. Kdo chce zkusit, pro toho mám několik doporučení.

Především se vykašlete na pluginy a používejte vanilla Emacs.[1]

Spousta lidí doporučuje používat plugin Evil, který od Emacsu přináší prostředí a prstoklad Vimu. Nedělejte to! Chcete-li pochopit, jak Emacs funguje, je lepší, alespoň zpočátku, používat emacsovský insert mód (jiný nemá) a klávesové zkratky. Mají svou logiku, ač se vi-lainovi může zdát cizí.

Pro začátek nedoporučuju používat ani Ivy a podobné pluginy usnadňující vyhledávání funkcí a dalších věcí. Důvody jsou stejné jako u Evil. Tyto věci znesnadňují pochopit Emacs tak, jak skutečně je.

Kdysi jsem se snažil Emacs používat jako hlavní editor a začal jsem u Spacemacs, tj. Emacs plus Evil plus Ivy plus dalších milion pluginů, jejichž ovládání je přes veškerou snahu autorů vzájemně ne zcela kompatibilní a způsobuje zmatek. Částečně poučen jsem instaloval čistý Emacs a narval ho pluginama sám. Výsledek nebyl lepší, spíš naopak. S Vimem mám dost podobnou zkušenost. Je třeba volit a přidávat pluginy velmi opatrně.

Dále doporučuju používat architekturu server-klient. Tzn. spustit Emacs jako daemona při spuštění počítače, pak je spouštění klientů rychlejší. Zejména pokud Emacs používáte na otevírání souborů odjinud, tedy nikoli přímo z Emacsu.

Mám radši Emacs bez lišty, nabídek a vstupní obrazovky a tyto věci lze v konfiguračním souboru snadno vypnout, ale pro začátek to nedoporučuju.[2] Emacs je čistokrevný GUI program, ačkoliv má i CLI verzi. Používáte-li Xorg, není důvod nepoužívat GUI verzi. CLI není rychlejší a GUI se dá zjednodušit tak, že prakticky vypadá jako CLI. Kdo s Emacsem začíná, tomu doporučuju standardní vzhled. Když něco člověk neví, často se k tomu dokliká přes nabídky.

Na druhou stranu přijde čas, kdy je dobré se od berliček odstřihnout. Člověka to donutí se do programu skutečně ponořit.

Org-mode

Tolik o Emacsu a nyní se přesuneme k Org-mode. Tento plugin od Carstena Dominika je důvod, proč mnoho lidí vůbec používá Emacs.

Org-mode je outliner, o kterých jsem tu už psal. Ale je mnohem víc. Koneckonců Org-mode ani Emacs samotný se zrovna neřídí unixovskou filozofií, aby program dělal jednu věc a dělal ji dobře. Jenže každé pravidlo má smysluplné vyjímky.

Org-mode je nepochybně overkill. Tím chci říct, že umí nákupní seznam, ale kdo by ho k tak primitivnímu účelu používal? Leda s aplikací do telefonu, která pro Org-mode také existuje!

Ale seznamy mohou být mnohem komplikovanější a s Org-mode je lze poměrně snadno řídit díky hierarchickému uspořádání. Zdroj je pořád TXT soubor, zároveň je k dispozici lehký markup, sofistikovaný todo list a systém hyperlinků. Hodí se jako nástroj pro dokumentaci, osobní wiki i plánovací kalendář. Nebo všechno dohromady.

A tady se dostáváme k jádru věci. Tím je dle mého soudu systém jednoho souboru. Vše v jednom dává smysl, pokud je k dispozici nástroj ke snadné manipulaci s komplexním souborem. Tzn. mít přehled o hlavních a vnořených tématech, snadno se dostat k hledanému, mít možnost vytvářet dílčí přehledy. K tomu časové značky, schedule, deadline, tagy a export do jiných formátů. Díky Org-mode lze skutečně „žít“ v jednom souboru. Neznamená to, že musím nutně mít pouze 1 soubor, spíš mít hlavní dokument, jakýsi hub, odkud se dostanu ke všem ostatním.

Přirozeně to není jediný způsob, jak organizovat své věci, psát dokumentaci, osobní wiki a jinou beletrii. Obyčejný textový editor a sada unixovských nástrojů nahradí valnou část všeho, co nabízí Org-mode. Princip jednoho souboru se v tomto případě zdá být spíše nepraktickým, ale další omezení Org-mode zde neplatí. Uspořádání TXT souboru je čistě na nás, žádný markup nás neomezuje, s vyjímkou souboru pro calendar(1). Některé věci, jako export do různých formátů, však k dispozici nejsou nebo vyžadují specializované nástroje jako lowdown(1) či texinfo(1), jež jdou nad rámec základního systému a nutí člověka používat nějaký markup. Termináloví asketové toto beztak nepotřebují. Co jde nad rámec souborů sdílených přes gopher, je od zlého.

Jaký je můj verdikt? Vcelku pozitivní. Emacs a Org-mode mají jednu velkou výhodu: jsou multiplatformní. Kdo je nucen pracovat ve Windows, má k dispozici přesně tentýž nástroj. TXT je samozřejmě také univerzální, ale unixovské nástroje už nikoliv a mě se na Windows nikdy nepodařilo docílit stejně hladkého workflow. I Vim je multiplatformní, včetně pluginů, takže není vyloženě nutné přesedlat na Emacs. Na druhou stranu Vim a Org-mode nejdou dohromady. Org-mode je šitý na míru Emacsu a žádný z vimovských pluginů ho neumí dobře. Kdo chce užívat Org-mode, měl by se naučit Emacs.

Nyní bude řeč o dvou Emacsech, které jsou konzistentní s unixovskou filozofií.

Mg

Editor mg(1) Je jedním ze čtyř základních editorů na OpenBSD.[3] Samozřejmě jsem ho zkoušel, ale nikdy konzistentně nepoužíval. Podobně jako vi neumí Unicode. A podobně jako vi je malý rychlý a určený výhradně k editaci textu. V manuálu k němu je jedna krásná věta, která dává odpovědi na všechny otázky:

It is compatible with emacs because there shouldn't be any reason to learn more editor types than emacs or vi(1).

Vile

Dostáváme se do neprobádaných končin. Thomas Dickey z invisible-island.net je když už ne tvůrcem, tak alespoň udržovatelem několika velmi známých programů. Xterm(1) není třeba představovat. Příznivci surfování na vlnách internetu a gopherové speleologie zajisté znají lynx(1). Mnohem méně lidí, troufám si tvrdit, zná vile(1) neboli VI Like Emacs.

A je to škoda. Jde o čistokrevný vi-like editor, který se lehce otřel o emacsový svět a odnesl si z něj pár lepších nápadů. Čistokrevný znamená, že můžete očekávat chování tradičního vi či nvi, nikoliv Vim. Proto se budeme nadále bavit jen o tom, co nedělá jako vi.

Co první udeří do očí, je způsob, jakým vile pracuje s buffery a okny. Tady je Emacs vidět asi nejvíc a je to dle mého soudu pohodlnější způsob práce s více soubory nebo s více pohledy na jeden soubor než u nvi. Podobně jako u Emacsu lze skrolovat buffer v druhém okně, aniž by bylo třeba tam přesouvat kurzor. Tento příklad dobře ilustruje emacsovské chápání bufferu jako kontajneru na texty, se kterými člověk pracuje. Mohou to být otevřené soubory nebo nové, dosud neuložené odstavce textu či výstupy externích programů.

Naproti tomu nvi používá buffery pro ukládání textových výňatků, nikoliv otevřených souborů. Ve vile k tomuto účelu slouží registry a přistupuje se do nich stejně jako v nvi, tedy s pomocí uvozovek a čísla či písmena. Také nvi umí editovat více souborů najednou a umí rozdělit okno na dvě části, přičemž v každé lze editovat jiný soubor nebo jinou část souboru. V tomto ohledu má dokonce výhodu, umí rozdělit okno i svisle, zatímco vile pouze vodorovně. Ale vile buffery čísluje a umožňuje snadnější a interaktivnější způsob, jak mezi nimi přepínat. Dvě podtržítka za sebou přepnou na předchozí buffer. Jedno podtržítko zobrazí očíslovaný seznam bufferů, takže podtržítko-číslo skočí na příslušný buffer. Hvězdička zobrazí seznam bufferů v jiném bufferu. Změny jsou vázány na buffer, nikoli na okno, takže undo je možné provést v jiném okně než původní změnu.

Mimochodem, pro všechny extra funkce vile zavádí emacsovské kontrolní sekvence ^A a ^X. To první mě trochu mrzí, neboť ve nvi poměrně často využívám vyhledávání slova pod kurzorem. Na druhou stranu tyto sekvence v kombinaci s tradičními příkazy vi často modifikují chování těchto příkazů.

Další myšlenkou převzatou z Emacsu je major-mode. S touto částí jsem zatím příliš neexperimentoval, ale všiml jsem si při editaci javascriptů, že je takový major-mode spuštěn a že to má vliv na odsazení textu. Zjevně vile obsahuje celou řadu těchto módů už v základu a další se dají naprogramovat, neboť vile dává k dispozici jednoduché API. To se sice nedá ani zdaleka srovnat s Elispem nebo Lua, ale chování editoru jím lze docela dobře ovlivnit.

Sekvence M-x v Emacsu umožňuje spustit interní funkci či příkaz. V Emacsu je vlastně všechno funkce s interním názvem a pro některé z nich existují základní klávesové zkrakty. Ve vile se funkce také dají spustit pomocí názvu, přes dvojtečku jako standardní vi příkazy. S pomocí těchto příkazů se právě programují pluginy či konfigurace editoru, což myslím také kopíruje funkcionalitu Emacsu.

Odhodlal jsem se k dlouhodobějšímu používání tohoto editoru a zatím jsem spíše příjemně překvapen. Nejspíš je to dáno tím, že jsem se nemusel učit mnoho nového. Po většinu času si skutečně vystačím s tím, co znám z (n)vi. Používání bufferů je snadné a hodnotím ho velmi pozitivně. Větší interaktivita editoru je někdy velmi příjemná a jindy zase ne. Trochu mě to zaskočilo u substituce, kde se program ptá na jednotlivé proměnné příkazu substitute. Součástí filozofie (n)vi je příkaz jako krátký program, což ve nvi výborně podporuje miniokno s příkazovou historií, jež hojně využívám. Interaktivita se s tímto pojetím poněkud míjí. Dosud jsem neprověřoval příkaz global, ale v manuálu je o něm poměrně dlouhé povídání, takže asi také doznal určitých změn. Nic z toho ovšem není game changer.

Chybí ex(1), který by se ve vile dle autora jmenoval exile, ale ten zas tak moc nepostrádám.

A tím končí můj výlet do neznámých vod, jimiž nevedou mé běžné lodní trasy. Občas je zajímavé zkoušet (staro)nový software, zejména od starších od programátorů. Snad díky omezení na straně hardwaru o své práci více přemýšleli a jejich programy jsou takové nenápadné perly, ač po nich dnes už pes neštěkne. Vile k takovým programům rozhodně patří.

EOF