One goes Emacs, never goes back

Azon felületen, amelyen akciókat egy grafikus mutató eszközzel lehet kiváltani, a támogatásával elvégzett feladatok hatékonyságukban sohasem mérhetők össze egy parancsszakkal vezényelt környezettel. Míg a pointeres környezetben tetszőleges tág időintervallumban indukálhatók olyan események, amelyek nem visznek közelebb a megoldáshoz, addig egy utasításokat fogadó bemenet késztetést ébreszt arra, hogy értelmes parancsot tápláljunk bele.

Hippivel gyakorlatilag a végtelenségig tudnánk arról diskurálni, hogy a hagyományos értelemben vett fejlesztői IDE-knek valójában mennyi létjogosultsága van egy programozó asztalán. Az ellenoldalt természetesen az Emacs (neked Vim) képviseli. El tudok képzelni olyan fejlesztői munkakörnyezetet, olyan méretű komplexitást egy projekt részéről, hogy egy mindenféle képességgel teletömött integrált környezet valóban sokat lendídhet a feladatok menedzselésén, magasabb absztrakciós szintről nyújt áttekintést a kódsorok tartalmáról. Ezen felvetésre természetesen rögvest adódik felelet; az Emacs pedig egy editor, egy bővíthető (extensible), testreszabható (customizable) text editor (with a built in kitchen sink, and a circus tent).

Valójában a beszélgetést mindig igyekszem úgy csavarni, hogy [nekem is] igazam legyen. A legtöbb, relatív kis projekteken dolgozó fejlesztőnek nincs szüksége Eclipse-re. Az alap kiszerelésben érkező szerszámok tárháza valóban kívánatos, mégis a Weblaboron még régebben nyitott Eclipse-PDT témához fűzött megjegyzés ad nekem igazat; a hozzászóló nagy megelégedése mellett azt panaszolja, hogy folding csak osztályra, függvényre működik, nem lehet állományonként megadni a használandó karakterkódolást, fájlnévben pedig nem engedi a pont (dot) karakter használatát. Utóbbi ponttól eltekintenék, hiszen emögött csupán metodológiai megfontolás lapul – nem beszélhetünk korlázotott funkcionalitásról –, valójában valamennyi további hiányosságként aposztrofált feature pedig az Emacs (neked Vim) velejárója.

A kérdéskör veleje azon a mezsdjén éleződik, amellyel legelőször akkor szembesültem, amikor a CHIP cédékről anno felhúztam a Slinket. Telepítsek egy minden programcsomagot (értsd: alkalmazást) tartalmazó OS-t, és utólag távolítsam el azt belőle, nekem ami nem kell, vagy építsem fel téglánként a várat a saját kedvem szerint? Ugyanez az analógia átülthető a fejlesztői környezet megválasztására, kialalakítására is. A különbség mindösszesen az, hogy míg egy konkrét disztribúció esetén ugyanazon építőelemek állnak a rendelkezésre – tehát bármelyik opciót is választjuk, a két megoldás egészen addig közelíthető, mígnem találkoznak –, addig egy hízó IDE szolgáltatáskörét kiterjeszteni keményebb feladat. Nem beszélve arról, hogy az Emacs (neked Vim) tengernyi kiforrott eszköz (GNU és UNIX utils) tetején ül, amelyek többnyire csak az IDE elhagyásával érhetők el.

A 2007-es hazai Drupal konferencián CHX előadása nyújtotta végül azt a megállapítást, amely ennek a bejegyzésnek lezárásául is szolgál. A Kate-tel kivitelezett Drupal kódtömeg becserkészése ébresztett rá arra, hogy mit nekem fennkölt az IDÉ-k szerepét veséző gondolatok, miközben a problémák valójában a használt editor vagy magasabb környezet a fejlesztőre észrevétlenül gyakorolt megszokásokból erednek. Amikor kézzel indentelsz, amikor karakter pozicióhoz kurzorral lépsz oda, hogy backspace-ek hadával törlöd a nemkívánt kifejezést, amikor olyan magatartásformák rögzülnek benned, amelyek az IDE sajátos jellemzői, amikor érzed, hogy a felvetett problémára van jobb megoldás is, de a te editorod csak ezt tudja.

Neki Eclispe (VS, NetBeans, Kate sít), neked Vim, nekem Emacs. Igen, és bizonyára vannak TextMate pártolók is.