A kevesebb több?

Miután kiskoromtól hobbim volt a programozás, később pedig publikálás és adminisztráció miatt erősen kötődtem a számítógépekhez, azon belül főleg a szövegszerkesztőkhöz, szinte folyamatosan kutattam az ideális szövegszerkesztő iránt. Persze ilyen nem létezik, de néha az ember rátalál egy-egy igazgyöngyre. Most lényegében két ilyet mutatnék be az elmúlt évezredből!

A megszokás nagy úr, a túlnyomó többség pedig nem hajlandó kilépni a komfortzónájából, s így elindulnak a hitviták, ha két olyan ember találkozik, aki mást szokott meg. Az informatikára ez fokozottabban teljesül, gondoljuk a vi-emacs, Windows-Linux-MacOs, Intel-Ryzen, ANSI-ISO billentyűzet, vagy a különféle Linux disztribúciók között fennálló ellentétekre. A portálon erre milliónyi példa található. Én szeretek tapasztalatok alapján meggyőződni az alternatívákról, s úgy alkotni véleményt. Az egyik ilyen sokáig halogatott területem a Plan9(wikipedia) illetve Plan9(homepage) volt.

Sokszor szembejött velem a Plan9, meg a most bemutatott programok is, de ezeknél valahogy nem működik a letöltjük, lefordítjuk, majd öt percet játszunk vele, és mindent tudunk róla. Saját tapasztalatból tudom, mert mindkettő - valamilyen formában - már megfordult a kezem között, aztán évek múlva megint szembe jött velem, és sokadik találkozásra már beletettem a kellő időt.

A Bell Labs irányában elfogult vagyok, és remélem, hogy e sorok olvasói is, mert itt született meg a Unix. Amiről már nagyon kevesen tudnak, hogy ugyanitt a Unix utódjának szánták a Plan9-t, amit az elmúlt évezred utolsó két évtizedében fejlesztettek. Természetesen Unix-szerű ez a rendszer, tehát elég könnyen bele lehet tanulni, viszont a filozófia nagyot változott: nem egy nagy szerver van, amelyhez terminálokkal férhetünk hozzá; hanem több kisebb szerver (dedikált fájlszerver, CPU-szerver, autentikációs szerver és esetleg grafikus terminálok), és így egyik gépen fut a program, mely a másik gépen tárolt fájlokkal dolgozik, miközben én egy harmadik gépről birizgálom a konkrét program grafikus felületét. S mindez egy negyed évszázada már működött. Természetesen van egy kis rajongói kör, mely ezt meg szeretné őrizni az utókornak ilyen-olyan formában. Ennek a révén tudtam kipróbálni az itt fejlesztett programokat. Hála nekik!

Ahogy a bevezetőben is írtam, számomra az egész rendszerből a szövegszerkesztők az érdekesek. Ezekről fogok írni, de előbb menjünk vissza az időben!

Unix standard editor

Nem, nem a vi-ról lesz szó. 1969-ben Ken Thompson egy assembler-rel, és egy shell-el együtt megírta az ed elnevezésű szövegszerkesztőjét. (Ha ismerős a név, az nem véletlen, részben ő volt felelős a C és Go programozási nyelvekért, az UTF-8 kódolásért, s sok már mindenért is.) Ez az a szövegszerkesztő, ahol nem létszükséglet a képernyő, mert akkor született, amikor a terminál még egy billentyűzet-nyomtató párost jelentett. S lényegében ilyeneken készült el az általunk ismert Unix, rendszerint ezzel a szövegszerkesztővel!

A vi(m) az ex parancsoknál lényegében az ed-re hivatkozik, illetve igen sok Unix-os parancsnak is az ed az alapja. Michael W Lucas Ed Mastery - The Standard Unix Text Editor - félig-meddig viccből megjelenő - könyve közel száz oldalon ismerteti az ed-et, ami szakértő kezekben csodákra képes. Egy kis ízelítő a program használatáról. 

Miután a nyomtató sor-orientált volt, ilyen lett a szövegszerkesztő is: sorokkal bővíthetjük a fájlunkat, sorokat törölhetünk belőle, a keresések eredményei sorok lesznek, stb.

Sam

Rob Pike - aki szintén a Go programozási nyelvről és az UTF-8-ról lehet ismerős -, a nyolcvanas évek elején írta meg a Sam szövegszerkesztőt (). Ken Thompson az ed-ről erre váltott át, de  Bjarne Stroustrup (C++),[4] Brian Kernighan (AWK, C könyv) is lelkes használói voltak ennek a programnak.

Míg a vi-ra úgy gondolhatunk, hogy az ed kapott egy karakteres felhasználói felületet (TUI), a sam egy valódi GUI-t kapott. A Plan9 miatt van még egy csavar a történetben, mert a nem kell ugyanazon a gépen futnia a szövegszerkesztőnek, mint ahol a grafikus felületünk is van. Másrészt az ember megszokta, hogy egy valamennyire számító szövegszerkesztőben van úgy kétszáz funkció, beleérve az egy szóval előbbre/hátrább ugrást, vagy a kijelölés kiterjesztését egy további karakterrel. Az már szövegszerkesztőtől függ, hogy ezt hogyan oldja meg. A modális szövegszerkesztők - mint a vi(m) is - bevezetnek olyan üzemmódokat, ahogy egy sima karakter leütésével egy hasonló parancsot hajtunk végre, például a w-vel a következő szó elejére ugrunk. Egyes számítások szerint az al-üzemmódokat is számolva 53 üzemmóddal rendelkezik a vim, és még így is rá vagyunk szorulva a Ctrl-betű kombinációkra. Igaz, aki beletesz pár évtizedet, a gondolat sebességével tud szöveget szerkeszteni. Más szövegszerkesztőknél ilyen nincs, de a Ctrl-x + Ctrl-s típusú kombinációk százait kellene megtanulni (s utána meg szenvedni az emacs-pinky-vel). Máshol ezek a parancsok egy menürendszerben lettek elrejtve, s már csak rajtunk múlik, hogy melyikhez, és milyen gyorsbillentyűt szeretnénk hozzárendelni.

A sam igen mostohán bánik a billentyűzetvirtuózokkal. A kurzor-nyilakkal haladhatunk, bár a fel/le nem egy sorral ugrik odább, a Delete a Backspace klónja, és még számíthatunk a Home/End, PgUp/PgDn billentyűkre és a Ctrl-a/Ctrl-e mozgásokra, meg a Ctrl-h, Ctrl-w, Ctrl-u törlésekre. Az Esc pedig kijelöli a legutóbbi kattintás óta begépelt szöveget. Ez nem tűnik biztatónak, de lássuk, hogy mit kapunk a grafikus felület, és a hozzá tartozó egér révén! Ez nem az Apple ökoszisztéma, bajban is vannak akik MacBook-on emulálnák a Plan9-t, ugyanis egy háromgombos egérre lenne szükség. A kattintható görgő határeset, nem igazán teszi gördülékennyé a használatot, másrészt itt biztos nem fogunk vele görgetni.

A három egérgombnak kitüntetett szerepe van, balról-jobbra haladva: kijelöl, végrehajt, fájlok. A jobboldali gombbal előjön a megnyitott fájlok listája, s felette a new, zerox, resize, close és write parancs. Természetesen mást fájlt kiválasztva az töltődik be az adott ablakba. A zerox segítségével ugyanahhoz a fájlnak egy újabb ablakot nyithatunk, így ugyanazon fájl különböző részeit nézhetjük egyidőben. A new-t zerox-ot és a resize-t választva ki kell jelölni egy téglalapot, ahol az adott fájl ablaka ezután megjelenik. Természetesen a parancsablak is ugyanígy átszabható, de hogy ide-oda vonszolhatjuk az ablakokat, azt felejtsük el!

A cut&paste megoldás a Smalltalk-80-ból jön, és ez mindenki számára ismerős: a bal egérgombot lenyomjuk, az egeret elmozgatjuk, és felengedjük a bal egérgombot. Ezzel kijelöltünk egy folytatólagos szövegrészt. Ha nem mozgott az egér a gomb lenyomása és felengedése között, azt hívjuk kattintásnak, és ha ezt viszonylag gyorsan megismételjük, akkor dupla-kattintásnak. Mindig van egy kijelölésünk. A sima kattintás egy nulla hosszúságú kijelölést generál a kattintás helyén. A dupla kattintás viszont helyzetfüggő. Szó közepén kijelöli a teljes szót, zárójel mellett (de belül) a zárójelek közti részt - hasonlóan idézőjeleknél -, a sor elején vagy végén pedig a teljes sort. Ha az aktuális ablakon kívül kattintunk, akkor pedig egy másik ablak lesz aktív.

Ha gépelünk, akkor kezdetben az aktuális kijelölés tartalmát írjuk felül, míg később azt bővítjük.

A középső egérgomb az harmadikhoz hasonlóan egy menüt hoz fel, de itt a cut, paste, snarf, look és a legutóbbi keresés reguláris kifejezése szerepel. A snarf utal egy rejtett puffer-re, ami helyett a copy név terjedt el azóta: a cut ide menti el a kijelölést, amit a fájlból töröl, a paste ezzel írja felül az aktuális kijelölést, míg a snarf a kijelölést elmenti, nem töröl. (Magyarul a Ctrl-x, Ctrl-v, Ctrl-c helyett egerezhetünk.) A look a kijelölés soron következő előfordulása után kutat, és azt jelöli ki, míg a reguláris kifejezést választva az után fogunk továbbra is kutatni.

Bármilyen a fura, a görgetősávon is kattintani kell. A bal egérgombbal előre, a jobbal hátra haladunk, arányosan a kattintás helyével: amelyik sor mellett kattintunk a jobb egérgombbal, az lesz az ablak első sora, míg a középső gombbal a görgetősáv közepére kattintva a fájl közepét fogjuk látni, persze elegendően hosszú fájl esetén.

Ezzel lényegében le is írtam a programot. A parancsokra most vesztegetnék időt és helyet. Csupán tőszavakban

  • szövegmanipuláció: beszúrás a kijelölés elé/mögé, csere, törlés, másolás, átmozgatás, helyettesítés
  • kijelölés kimásolása a parancsablakba (ott akár szerkeszthetjük is), a kijelölés pozíciója
  • fájlok beolvasása, mentése, bezárása, fájl tartalmának beszúrása a kijelölés helyére, Unix szkript végrehajtása a kijelölésen
  • ciklus és feltételes végrehajtása parancsoknak reguláris kifejezések alapján (halványan emlékeztethet a multi-kurzor-ra, bár annál jóval általánosabb)
  • undo

Aki semmit nem tud az ed-ről és vi-ról, annak nem nagyon lehet egy blogbejegyzésben megmutatni az előnyöket, hátrányokat. A vérprofi (n)vi(m) felhasználóknak meg kicsit át kell állítani a gondolkodásukat, mert itt már szöveg- és nem sor-orientált programról van szó, illetve a reguláris kifejezéseknél is sikerült szintet lépni: strukturális reguláris kifejezések vannak, valamint összetett címzés is elérhető. Lássunk előbb egy kedvcsináló videót egy vérprofi felhasználótól, majd egy részletesebb ismertetőt.

Acme

Rob Pike másik szövegszerkesztője az Acme. Fura, hogy filozófiájában mennyire el tud térni ez a két program, noha ugyanaz az alkotó. Az előbb ide-oda szabhattuk az ablakokat, és alapvetően egy parancsablakunk volt (meg esetleg annak a klónjai). Itt megadhatunk pár oszlopot és az ablakaink abban helyezkednek el, automatikus méretezéssel, amit igény szerint felülírhatunk, valamint mozgathatjuk az ablakokat az oszlopok között. Minden egyes ablakhoz tartozik egy fejléc, ami automatikusan kitöltésre kerül. Ebben szerepel az ablakhoz tartozó fájl neve, valamint parancsok. Igény esetén mi is írhatunk ide bármit. Nem csupán egy fájl szerepelhet egy ablakban, hanem hasonlóan a Unix filozófiához - mely szerint minden fájl -, egy könyvtár is egy ablakban jelenik meg, ahogy egy program futásának eredménye, vagy a hibaüzenetei. Emiatt megtehetjük, hogy a böngészőből kimásolt címet parancsargumentumként használva kiadunk egy git clone majd egy make parancsot, és semmit nem kellett begépelni a terminálba. Azt hiszem ez az a tulajdonság, mellyel el lehet adni a programot.

A bal egérgomb lényegében hasonló szerepet tölt be, mint korábban. A középső gomb a parancsgomb lesz, és nem tartozik hozzá menü. Ha rákattintunk vele egy parancsnak tekinthető szóra, akkor az végrehajtódik. A jobb oldali egérgomb a korábbi look-hoz hasonlít, adott szóra kattintva, annak következő előfordulását keresi. Viszont megérti a fájlneveket, a hozzájuk kapcsolódó sorszámokat, reguláris kifejezéseket, így például a fordító hibaüzenetére kattintva az adott helyen kinyitja a hibás fájlt, rövid javítás után kattinthatunk a Put (save), majd make parancsra; vagy pedig a következő hibaüzenetre.

Mivel a sam-hez képest elvesztettük a középső gombhoz tartozó menüt, egérgomb-kombinációkkal érhetjük el a cut-copy-paste funkcionalitást, ha nem akarunk az oszlop tetején található szavakra kattintani. Viszont összeállíthatunk olyan fájlokat, melyben a kedvenc parancsaink szerepelnek, melyeket egy-két kattintással elérhetünk. Például kijelöljük az argumentumot (a böngészőből kimásolt URL-t), majd a parancs fölötti kattintás-kombinációval alkalmazzuk rá. Lássunk megint egy kedvcsináló videót (a korábban szereplő vérprofi felhasználótól)! 

Elvileg a sam-ben megtalálható szövegmanipulációs parancsok többségét tartalmazza az Acme is, ám picinyke szkriptekkel, shell-beli függvényekkel még tovább bővíthetjük az Acme tudását. A comp.os.plan9 google csoportjában sok ilyen sok szkriptet osztottak meg a rajongók.

Az ezredforduló körül sokan játszottak azzal, hogy a levelezést, az Usenet hírolvasást, szótárprogramokat vagy honlapokat bekössenek az Acme-be, onnan használják.

Ez lenne a két program, s sajnálom, hogy én sem az ezredforduló táján találkoztam velük.

Ha a videókból nem derült ki, egyik program sem foglalkozik a szintaxis-kiemeléssel, ami sokaknak az utolsó csepp volt a pohárban, mert anélkül nem szövegszerkesztő egy program.

Hogyan tovább?

Érdekes tapasztalat, hogy az egyre inkább elbonyolított szövegszerkesztőknek vannak alternatívái, és ha időt és energiát fektetünk bele, akkor akár jobb, kényelmesebb környezetet is alakíthatunk ki magunknak. És már megint a Unix filozófiáját követjük! A szövegszerkesztő csak szerkessze a szöveget, illetve kommunikáljon a környezetével!

A rossznyelvek szerint az emacs és (n)vi(m) felhasználók onnan ismerhetőek fel, hogy többet foglalkoznak a szövegszerkesztőjük beállításaival, mint a konkrét munkával. Itt azért korlátozottabbak a lehetőségek, nem feltétlenül lesz egy nyúlüreg a konfigurálás. 

Az egérgomb-kombinációk egy-két nap alatt nem váltak természetessé számomra, és erősen élnek még bennem a korábbi beidegződések. Feltételezem hosszabb idő alatt bele lehet tanulni, hozzá lehet szokni. Az, hogy a szövegszerkesztőben nincs egy halom olyan funkció, melyet nem használok (lásd Pareto szabály), az engem nem zavar. Másfelől mindkét program kiegészíthető a szükséges eszközökkel, ahol az implementáció nyelve nincs előírva, és ez elégedettséggel tölt el.

Ha valaki ki akarja próbálni Linux vagy épp MacOs alatt ezeket a szövegszerkesztőket, akkor a https://9fans.github.io/plan9port/ oldalon érdemes elindulnia. 

Most már ezeket a programokat fogom használni a későbbiekben? Igen is, meg nem is. Munkám során a Linux-hoz vagyok kötve, ezen pedig a Plan9 szimulációja egy kicsit körülményes, ezért nem pont a sam és Acme mellett tettem le a garast, viszont az elveket, a lehetőséget meg kívántam tartani, így szétnéztem az alternatívák között.

A sam és vi házasításából megszületett a vis ami egy ideje az elsődleges szövegszerkesztőm. Ez karakteres, Ubuntu csomagként elérhető, de azért érdemes magunknak forrásból lefordítani. Úgy vélem, hogy a két ős legjobb génjeit sikerült átörökíteni, a mérete a vim és nvim méretének töredéke, s ha esetleg valami hiányozna a programból (amire bőven van példa: quickfix, fuzzy finding, word completion, stb), azt többnyire megoldotta Lua plugin-okkal a közösség. Ha a Json fájl hibás az 1542. karakternél egy egysoros fájlban, akkor azt is megtalálom másodpercek alatt a sam örökségéül megkapott szöveg-orientáltság miatt. Persze az sem okoz gondot, hogy bármikor a 924. sorra ugorjak, vagy az azt követő Markdown címre (lásd összetett címzés). Kis kényelmetlenség, hogy ez a program MacOS alatt vise névre hallgat, de általában úgyis csak v-ként hivatkozom rá itt is, ott is, tehát nekem nem zavaró. 

Fura módon más is megpróbálkozott ezzel a házasítással: https://c9x.me/edit/, ám itt egy grafikus felületű programot kaptunk, ahol a parancsablak csak külön kérésre kerül elő, és a vi-ból megszokott billentyűkombinációknak jelentős részét elhagyta, ami eléggé megnehezíti a váltást. Ezt a programot saját magunknak kell lefordítani, amihez be kell szerezni Knuth CWeb rendszerét is.  

Az Acme alternatívájaként a wily már többször is láttam, próbálgattam is - Ubuntu csomagból el is érhető -, de ég és föld a különbség, ha az ember 9base-el együtt vagy nélküle telepíti. Fontos, hogy rc legyen a kapcsolódó shell és ne a bash. A wily egy harminc éves program, nem sok ráncfelvarrása volt, még éppen használható, de azért nem ideális. Kezessé lehet tenni, de sok munkát kell beletenni, hogy megismerjük és beállítsuk, mert nincs túldokumentálva.

Ha ráguglizunk, akkor több Acme hasonmást is találunk. Lustaság miatt egyelőre kihagytam azokat, ahol nekem kell lefordítani - egy általam nem ismert programnyelven - a programokat. Így most az Anvil lehetőségeit próbálgatom, s próbálom beépíteni a munkafolyamataimba. Ennél a programnál az az érzésem, hogy sikerült túltolni a biciklit, mert belekerült egy halom, számomra felesleges funkcionalitás, illetve nagyon sok gyorsbillentyűt definiáltak, sőt még a kedveztek a MacOS használóknak is, mert billentyűkkel kiválthatjuk a második, meg a harmadik egérgombot. Ha valakinek megdobogtatta a szívét az Acme, akkor ránézhet erre is, de érdemes egyszer figyelmesen végigolvasni az elég részletes dokumentációt, végignézni az oktatóvideókat, és személyesen is végigoldani a kiadott feladatokat. Ugyanis csak ezután érdemes valóban használatba venni.  

Hozzászólások

Nekem nem adatott meg, hogy egy OS -en belül találjam meg az igazit. Muszáj voltam dolgozni Windows alatt notepad.exe -vel (mert akkoriban még csak az volt) és utána sokféle programot kipróbáltam, ami mind többet tudott a sima jegyzettömbnél. A notepad++ volt talán a legélhetőbb ezek közül, illetve a Visual Studio editora volt még nagyon jó, de az azért céleszköz, nem keverném ide. Egy időben a Total Commander editora volt a favorit, mert az elég jó volt, és fent volt a melóhely összes gépén.

Munka célra Linux és Unix alatt a nano/joe/vi/vim (mikor mi volt elérhető) működött jól, ezekkel vagyok kompatibilis. Rutinom vim -el van, mert azt használom 90% -ban, ha könyékig kell túrnom egy GUI nélküli gép lelkivilágába.

Viszont ami nálam mindent visz a szövegszerkesztés terén, az a Sublime Text. Igaz, hogy csak GUI -s gépen fut, viszont ugyanaz a (pyhton) program Linuxon és Windowson, vagyis nem kell agyilag átszokni másra, csak azért mert éppen más gépen vagyok. A több kurzoros mód a több vágólapos móddal zseniális amikor text alapú adatsorokkal kell bűvészkedni, osztott módban egy állományban több helyen szerkesztetek egyszerre (nem kell oda-vissza görgetni), színkiemeléstől kezdve automatikus kiegészítésig támogatja a programozást, igazi mindenes.

Szívesen olvasok írásokat ezekeről a rendszerekről/programokról.

Mostanában sokat foglalkoztam Niklaus Wirth professzor Oberon rendszerével. Annak a működése hasonló amit fentebb leírtál, ami az ablak, szöveg és parancs kezelést illeti.