Keskustelu: Yleinen keskustelu: Vi ja Vim

Kirjoittelenkin tämän alustuksen asiaankuuluvasti GVimillä, jonka laukaisin pikanäppäinyhdistelmällä selaimestani (Vimperator).

Onko putkassa paljon Vim-käyttäjiä? Otin ihan juurien muistamisen vuoksi otsikossa mukaan myös alkuperäisen Vi-toteutuksen, ja mikseivät kaikki muut kloonitkin mahtuisi tämän keskustelun alle. Korostakaamme valitsemamme editorin erinomaisuutta tässä ketjussa. Ehkäpä myös ratkomme ongelmia ja keskustelemme siitä, kuinka Vim ei pelkästään poista nälänhätää vaan myös ratkoo poliittiset ja taloudelliset ongelmamme maailmasta.

Kun minä aloitin käyttelemään vimiä muinoin vuonna 2006, ymmärsin jo silloin toki sen hyvät puolet ja mahdottoman joustavuuden liki mihin tahansa kuviteltavissa olevaan tilanteeseen. Silloin käyttelin vimiä lähinnä palvelimen hallinnoinnissa, kuitenkin useasti viikkoon ja ainoana editorina. Seuraavana vuonna vaihdoin pääasiallisen käyttikseni gentooseen, ja muutapa en käyttänytkään editorina kuin konsoli-vimiä. Joskus satunnaisesti gvimiä, mutta eipä muuta. Taidot karttuivat ajan saatossa. Ensimmäiset vuodet menivät pitkälti käytellessä vimiä kuin muistiota konsanaan: nuolinäppäimin liikuskellen ja insert-modessa hengaillessa kyllä jo yksinään saa rajoitettua ohjelmaa kovasti, mutta kaikki herkut periaatteessa oli ymmärryksen alla.

Sitten sitä vain jostain ykskaks huomaa käyttelevänsä ohjelmaa (ja muitakin) kotiriviltä käsin. Nettiä selatessa Vimperatorilla jk-pyöriminen on erityisen mukavaa, mutta kun myös perustyökalut, kuten less ja vaikkapa okular (pdf-lukija), tukevat näitä näppäimiä (lienevätköhän jossain määrin standardiinkuuluvia määreitä, vaiko pelkästään vi:stä omaksuttuja?) niin tuleehan sitä käyteltyä. Nyttemmin myös ikkunamanageri tottelee sen perinteisen alt-tabin sijasta mod-j/k -yhdistelmiä. Sitten sitä huomaa yllättäen hallitsevansa myös kaikki pikkukivat liikkumajutut: ( ja ), ]s ja [s, } { ja vaikka hitto soikoon %, jos tarve vaatii. Lateksia kirjoitellessa ja muutenkin ihmislukuisia selkodokumentteja tehdessä c( oli tuttu komento. Tuollaisista en osannut edes unelmoida osaavani ulkomuistista silloin vuosia sitten.

Kirjallisuutta olen ostanut sänkylukemiseksi; varsinaiset referenssit silti kaivan googlella ja ohjelman sisäänrakennetuista erinomaisista dokumentaatioista. Ensin tuli ostettua hyvä teos "Hacking Vim: --" Kim Schulzin käsistä. Paria vuotta myöhemmin ostin lisäksi perustavantasoisen paketin Learning the vi and Vim Editors, jossa on paljon hyvää tietoa, jolla pönkittää hyvin osaamista.

Aivan ensimmäinen opas, jolla opiskelin editoria, oli aika yksinkertainen sivupahanen, joka tuli luettua siinä sivussa kun asentelin gentoota ensimmäistä kertaa silloin nelisen vuotta sitten: http://www.gentoo.org/doc/en/vi-guide.xml. Eipä tuosta oikein sillä tavalla pääse vielä jyvälle, mutta kovin moni ei aivan heti halua maksaakaan kirjoista, etenkään jos ohjelmaan ei ole rakastunut heti ensisilmäyksellä.

Keskustelun ei tarvitse suinkaan koostua rinkionanoinnista. Esimerkiksi vim-skriptauksen saloja ja potentiaalia voisi peräänkuuluttaa. Koodaavatko naavaparrat täällä vain alkuperäisiä vi- tai ex-makroja käytettäväksi suoraan bourne shellistä? Vai ovatko ruby, python ja perl sisäänrakennetun vimscript-kielen lisänä aktiivikäytössä.

Emacs-miehet: perustakaa oma vastaava ketju, jos mielitte. Minua kiinnostaisi kyllä kovasti seurata sellaista, jos samalla kaavalla luotaisiin. Sama kielto koskee muitakin, ketkä eivät ymmärrä hyvän päälle. ;)

pico, nano tai TextMate

progo kirjoitti:

(lienevätköhän jossain määrin standardiinkuuluvia määreitä, vaiko pelkästään vi:stä omaksuttuja?)

vi:n kautta ne on muualle omaksuttuja. Joy ne nappasi aikanansa, koska käytti terminaalia, jossa nuolinäppäimet olivat niissä näppäimissä. Terminaalin tyyppiä en muista.

Käytöstä löytyy nex/nvi (vi:n perillinen suoraan alenevassa polvessa) FreeBSD:llä ja fiinimmissä ympäristöissä Solariksen ja Tru64:n mukana tulevat. Vielä en ole ainakaan törmännyt mihinkään vim:n tarjoamiin erikoisuuksiin, joita kaipaisisin.

Vaikka ei muuten haluausikaan viä käyttää, kannattaa peruskäyttö kuitenkin hallita, koska sitten pääsee helpommalla, kun järjestelmässä ei olekaan näyttöeditoreista kuin vi, ja kuitenkin suurin osa ex-komennoista kelpaa rakkaalle edillekin, kun /usr leviää käsiin eikä cursesista ole toivoakaan. :p

fronty kirjoitti:

Vaikka ei muuten haluausikaan viä käyttää, kannattaa peruskäyttö kuitenkin hallita, koska sitten pääsee helpommalla, kun järjestelmässä ei olekaan näyttöeditoreista kuin vi, ja kuitenkin suurin osa ex-komennoista kelpaa rakkaalle edillekin, kun /usr leviää käsiin eikä cursesista ole toivoakaan. :p

Näin on. Tosin itse kyllä vaihtaisin jo systeemiä väliaikaisesti toiseen, jos on niin pahasti sotkeentunut systeemi, ettei curses pyörähdä käyntiin. Samalla pitää ihmetellä, miksi vimin oheistuotteena tarjoama ex toimii sekin cursesin pohjalla, vaikka kunnon rivieditorina se voisi karsia graafisesta ulostulosta enemmän, ja turvautua vaikka pelkästään standardikirjastojen syötekirjastoihin.

En tiedä, käytätkö sinä sitten esimerkiksi jotain graafista IDEä tai vastaavaa "oikeissa" askareissa, minulle ei mikä tahansa vi-klooni oikein kelpaa, osassa kun ei ole edes syntaksivärjäyksen ylellisyyttä. Vimin laajennettavuus tekee siitä melko näppärän skriptikielen kanssa emacsin laajuutta lähentelevän paketin, mikä ei minusta lainkaan huono homma ole, kun modaalisuus pitää sormet poissa controllilta kuitenkin. Itse olen kuitenkin lähtenyt ihan siltä pöydältä liikkeelle, että vimin erikoisominaisuudet kannattaa opetella ihan niiden itsensä vuoksi, eikä ajatella turhuuksina. Ymmärrän kuitenkin hyvin myös käänteisen ajattelutavan. Senpä takia niitä muita klooneja lieneekin edelleen elossa.

Sehän on selvä asia. Se on yksi ja sama tekstieditori. Se tarkistaa argv[0], ja pistää alkuasetukset sen mukaisiksi. ex -> rivieditori, vi -> näyttöeditori, view -> read-only näyttöeditori. Kokeile vaikka cmp `whichi vi` `which ex`. :p Kyllähän sen saisi sitenkin hoidettua, että kun käynnistää nimellä ex, komento vi hakee kaikki funktiot käsin dl*(3)-perheen kautta, mutta onko se sen arvoista?

Ihan vi:llä kaikki hoituu kaikki paitsi Haskell-ohjelmointi, jota teen Emacsilla ( :'( ), jossa automaattinen sisennys ja koodin lähetys ghci:lle on erittäin käteviä. Muissa tapauksissa en kaipaa mitään hienouksia kuten syntaksivärjäystä tai automaattista sisennystä, Haskellinkin yhteydessä jälkimmäisestä pidän, koska siinä kielessä sisennyksellä on väliä. Aina, kun jostakin syystä käyttää NetBSD:tä, on hirveä totuttelu, jos kirjoittaa jotain ohjelmakoodia, kun ovat menneet patchaamaan (ainakin) C:tä varten automaattisen sisennyksen, eikä koskaan äkkiseltään jaksa tonkia, mistä sen saakaan pois päältä. :p Onneksi FreeBSD ei ole sellaista patchia napannut.

Minä en oikein ymmärrä, miksi joku haluaisi tekstieditoristansa niin suuresti laajennettavan. Eikö se riitä, että sillä saa kirjoitettua tekstiä? Sen ymmärrän, että voi lisätä tukea eri ohjelmointikielille, jos tekstieditori tarjoaa syntaksivärityksen ja automaattisen sisennyksen tyyppisiä systeemejä, mutta muu menee IMO turhaksi leikkimiseksi. On tosin nex/nvi:ssäkin Perl-tuki. 8)

Olen vahvasti jonkin vimin skriptikielen tai muun sensorttisen käyttämistä vastaan. Bourne shell ja standardityökalut pitäisivät riittää, koska sitten se ainakin toimii muissa järjestelmissä. Yhteensopivuuden rikkominen jollakin vim-riippuvuudella on ihan hullua.

Siitäkös se johtuu, että lähes kaikki Xmonad-käyttäjät ovat samalla emacsisteja. Onneksi siihen oli joku järkiperustelu }:)

Editorien ominaisuuksia minä lähtökohtaisesti kannatan, koska juuri vimiä opiskellessani olen havainnut, että ihminen tekee paljon turhaa näppäilytyötä pitkälti ei-minkään tähden. Laajennettavat systeemit tukevat sitten tavalla tai toisella makrojen lisäilyä sekaan soppaan. En enää vapaaehtoisesti kirjoita mitään XML-kieltä, ellei editori osaa sulkea lähimpänä auki olevaa tagia yhdellä näppäinpainalluksella (vimscriptissä onelineri), ja LaTeX-koodissakin lähimpänä suljettava ympäristö menee sekin yhdellä näppäinkomennolla, mutta siihen pitikin itse paneutua ja tuottaa huimaava laskentatavasta riippuen 5-7 -rivinen proseduuri. Tuottavuuden suhteen tunnen olevani vimin kanssa todella huipulla. Tämä käynee myös samalla omaksi perustelukseni oman skriptikielen valinnalle. En minäkään käytä sitä yleisluontoisiin ohjelmiin (tosin eräässä bash-skriptissä käytän ex-ohjelmanpalasta, mutta ex on vielä jokseenkin POSIX-universaali) mutta ohjelmansisäiseen toiminnallisuuden kirjoittamiseen oma kieli on hyvästä, jos se helpottaa sitä integroimista sisään.

E: ja käyttöohjelmien laajennettavuus itsessäänkin taitaa olla pitkälti ihan makukysymys; osa ei osaa erota Firefoxista, koska muut selaimet eivät laajene haluttuihin toimintoihin yhtä joustavasti, ja jotkut tykkäävät vaikka Chromen pelkistetystä perusjutut-löytyvät-ja-homma-toimii-nopeasti -tyylistä.

fronty kirjoitti:

Minä en oikein ymmärrä, miksi joku haluaisi tekstieditoristansa niin suuresti laajennettavan. Eikö se riitä, että sillä saa kirjoitettua tekstiä?

Jos asia olisi näin yksinkertainen, ed ja tyhmä terminaali riittäisivät kaikkeen. Kuitenkin visuaalisuus ja monipuoliset navigointiominaisuudet helpottavat tekstin kanssa työskentelyä. Usean eri tiedoston avaaminen tekstieditoriin rakennettuihin puskureihin on todennäköisesti kätevämpää kuin screen tahi tmux, koska tekstieditori tuntee puskurin sisällön ja tarkoituksen. Automaattisisennyksen ja syntaksivärjäyksen käyttö on mielipidekysymys, mutta niiden hyödyllisyys lienee varsin hyvin perusteltua. Yhtälailla eri merkistöjen ja rivinvaihtokäytäntöjen hallinta on tärkeää ja joskus välttämätöntä. Makrot ja skriptit säästävät aikaa monessa tilanteessa. Myös ulkoisia työkaluja komentamalla voidaan automatisoida tehtäviä.

Jos editoriin on rakennettu monipuolinen ja kustomisoitava käyttöliittymä, menetelmiä usean tiedoston käsittelyyn, värjäys ja sen edellyttämä parsinta, makrot, skriptit, merkistöjen hallinta, kaksisuuntainen kommunikaatio prosessien kesken, ym., niin miksei näitä voisi hyödyntää muussakin kuin levyllä lojuvaa tiedostoa koskevassa tekstin kirjoittamisessa? Kirjoitan juuri nyt foorumille. Selaimessa on monta "puskuria", joita täytyy hallita. Sivuilta täytyy toisinaan etsiä tiettyjä merkkijonoja. Ilman monipuolista navigointia olisi surffaaminen aika ankeaa.

Sama kaava toistuu irkissä: "syntaksivärjäys" helpottaa hahmottamista. Kirjoitusvirheitä punataan ja tabilla täydennetään nikkejä tai työläitä sanoja. Kanavia (puskureita) on useita. Merkistöt täytyy hallita, sillä luen ja KIRJOITAN muutakin kuin englantia. Haulla löydän nopeasti scrollbackista tietoa. Pinnan alla softa käy kaksisuuntaista keskustelua irc-palvelimen kanssa.

Irkkaan Emacsilla. Kirjoitan Emacsilla. Toisinaan käytän Emacsia shellinä ja web-selaimena. Tutut näppäinyhdistelmät ja komennot ovat siis jatkuvasti saatavilla. Toinen vaihtoehto olisi käyttää kaikkeen erikseen kyhättyä ohjelmistoa, mutta silloin jää aina jotain kirjoittelulle, navigoinnille, ym. oleennaista toiminnallisuutta puuttumaan – ellen sitten ota osaa ko. softan kehityksessä. Mutta mitä turhaan keksimään pyörää uudestaan?

Vimiä käytin 4-5 vuotta. Sitten kiinnostuin lispistä. Ei vaan löytynyt kovin pätevää keinoa saada Vimiä ja REPLiä keskustelemaan keskenään. Paras oli screenillä toteutettu viritelmä, joka heitti vimistä screenissä pyörivään repl-sessioon palan koodia. Hyi kun on kankeaa kunnollisen repl-integraation rinnalla.

jcd3nton kirjoitti:

Jos asia olisi näin yksinkertainen, ed ja tyhmä terminaali riittäisivät kaikkeen. Kuitenkin visuaalisuus ja monipuoliset navigointiominaisuudet helpottavat tekstin kanssa työskentelyä.

Tästä olen samaa mieltä. En silti nää mitään syytä sille, että tekstieditorista saa tehtyä kahvinkeittimen, kun se kerran on tekstieditoriksi tehty.

Täytyy kyllä myöntää, että viestini kertoi mielipiteeni aika vajaasti, aka väärin. Jos editorissa on jotain erillistä ohjelmoinnin tueksi, ymmärrän eri ohjelmointikielten tuen lisäämisen näissä puitteissa hyvin. Tekstin editoinnin helpottavasta räpeltelystä en lähde kivitystuomioita jakamaan, mutta ylenpalttinen laajentaminen on minusta turhaa, kyseessähän on sentään tekstieditori.

lainaus:

Usean eri tiedoston avaaminen tekstieditoriin rakennettuihin puskureihin on todennäköisesti kätevämpää kuin screen tahi tmux, koska tekstieditori tuntee puskurin sisällön ja tarkoituksen.

Edit bufferit ovatkin ihan mukavia. Jos käytössä on X (eli kirjottelen PC:llä), en vi:n kanssa tosin paljoa edit buffereita käytä, koska XMonadin kanssa ikkunoiden hallinta luontuu niin hyvin, että pärjään nopeammin ja helpommin, kun vaihtaa xtermistä toiseen, kuin vaihtamalla bufferista toiseen.

lainaus:

Automaattisisennyksen ja syntaksivärjäyksen käyttö on mielipidekysymys, mutta niiden hyödyllisyys lienee varsin hyvin perusteltua.

Näin on.

Yhtälailla eri merkistöjen ja rivinvaihtokäytäntöjen hallinta on tärkeää ja joskus välttämätöntä. Makrot ja skriptit säästävät aikaa monessa tilanteessa. Myös ulkoisia työkaluja komentamalla voidaan automatisoida tehtäviä.

Jos editoriin on rakennettu monipuolinen ja kustomisoitava käyttöliittymä, menetelmiä usean tiedoston käsittelyyn, värjäys ja sen edellyttämä parsinta, makrot, skriptit, merkistöjen hallinta, kaksisuuntainen kommunikaatio prosessien kesken, ym., niin miksei näitä voisi hyödyntää muussakin kuin levyllä lojuvaa tiedostoa koskevassa tekstin kirjoittamisessa? Kirjoitan juuri nyt foorumille. Selaimessa on monta "puskuria", joita täytyy hallita. Sivuilta täytyy toisinaan etsiä tiettyjä merkkijonoja. Ilman monipuolista navigointia olisi surffaaminen aika ankeaa.

lainaus:

Sama kaava toistuu irkissä: "syntaksivärjäys" helpottaa hahmottamista. Kirjoitusvirheitä punataan ja tabilla täydennetään nikkejä tai työläitä sanoja. Kanavia (puskureita) on useita. Merkistöt täytyy hallita, sillä luen ja KIRJOITAN muutakin kuin englantia. Haulla löydän nopeasti scrollbackista tietoa. Pinnan alla softa käy kaksisuuntaista keskustelua irc-palvelimen kanssa.

Tässä mennään sitten jo ihan eri asiaan.

lainaus:

Irkkaan Emacsilla. Kirjoitan Emacsilla. Toisinaan käytän Emacsia shellinä ja web-selaimena. Tutut näppäinyhdistelmät ja komennot ovat siis jatkuvasti saatavilla. Toinen vaihtoehto olisi käyttää kaikkeen erikseen kyhättyä ohjelmistoa, mutta silloin jää aina jotain kirjoittelulle, navigoinnille, ym. oleennaista toiminnallisuutta puuttumaan – ellen sitten ota osaa ko. softan kehityksessä. Mutta mitä turhaan keksimään pyörää uudestaan?

Makunsa kullakin, mutta minä en koe menettäväni mitään siinä, että irkkaan irssillä, kirjoitan vi:llä, terminaaliemulaattorina käytän xtermiä ja webbiä selaan operalla.

lainaus:

Vimiä käytin 4-5 vuotta. Sitten kiinnostuin lispistä. Ei vaan löytynyt kovin pätevää keinoa saada Vimiä ja REPLiä keskustelemaan keskenään. Paras oli screenillä toteutettu viritelmä, joka heitti vimistä screenissä pyörivään repl-sessioon palan koodia. Hyi kun on kankeaa kunnollisen repl-integraation rinnalla.

HAVE YOU READ YOUR SICP TODAY? Lisp-perhe on erittäin mukava niinkuin muutenkin funktionaalinen ohjelmointi. Nykyään minulla funktionaaliseksi kieleksi suurimmalti osin vaihtunut Haskell. :$

Vimin omien puskureiden käytössä on se ilmeinen etu, että ohjelman omia rekistereitä voi käyttää leikkailuun ja liimailuun. Vim toki tukee X:n leikepöytääkin, mutta siinä on ylimääräinen rekisterinvalinta. Jaan itse töitä monelle vim-prosessille kyllä, mutta siinä on selkeätä hierarkiaa kuitenkin tavattavissa: en yleensä samaa projektia hajauta usealle vim-prosessille ainakaan pitkäksi aikaa. Yleisin homma voisi olla esimerkiksi avata tilapäinen vim Makefile -sessio korjatakseni vaikkapa jonkun objektin lisää sinne. Vimissä kun tuo aukiolevien bufferien sulkeminen on aika työlästä ilman näppärää lisäosaa.

Puristit käyttävät yhtä vim-ajoa kaikkeen, kuten he käyttäisivät Emacsia. Ja he hierarkioivat kullekin projektille oman tabinsa. Mutta minusta se on erityisen epäkäytännöllistä, koska "buffer pool" on koko vim-session välinen. En haluaisi kierrätellä projektien X ja Y avoimia puskureita projektin Z ikkunassa. Ehkäpä en vain osaa, ja sieltä löytyykin joku täppä, jolla vimin tabeista saa hieman enemmän käyttökelpoisia kuin mitä ne nyt ovat.

Kyllä ymmärrän senkin argumentin hyvin, että unix-filosofisesti ajateltuna vain "vi" on oikeaoppisesti rakennettu tekemään tekstin editoimista ja vain sitä, mahdollisimman tehokkaalla tavalla. Vim valuu kohti yleiseditoria ja Emacs ei ole muuta koskaan ollutkaan. Ei anneta sen kuitenkaan häiritä. Melkeinpä voisin sanoa, että käytettävän ikkunamanagerin on oltava erityisen surkea, jos käyttäjä kokee tekevänsä monia eri hommia tehokkaammin saman ohjelman (vaikkapa Emacsin tai täystuunatun Vimin sisällä) kuin usean erikoistuneen ohjelman kanssa.

Kannatan unix-filosofiaa kovasti. Siltikin nostan hattua editorille, josta saa halutessaan kahvinkeittimen, koska yhteen käyttöön erikoistettu ja viritelty ohjelma ei poissulje laajennettavuutta. Ei sitten mitenkään.

fronty kirjoitti:

Edit bufferit ovatkin ihan mukavia. Jos käytössä on X (eli kirjottelen PC:llä), en vi:n kanssa tosin paljoa edit buffereita käytä, koska XMonadin kanssa ikkunoiden hallinta luontuu niin hyvin, että pärjään nopeammin ja helpommin, kun vaihtaa xtermistä toiseen, kuin vaihtamalla bufferista toiseen.

Koitin selventää tuota, kun sanoin, että editorilla on ymmärrys buffereiden sisällöstä (toisin kuin ikkunamanagerilla). Tietyt erityiskäyttöön tarkoitetut puskurit aukeavat automaattisesti kun niitä tarvitaan, tai niihin pääsee käsiksi kätevällä näppäinyhdistelmällä. Muut puskurit löytyvät ainakin Emacsilla kätevästi idolla. Kyseessä on siis puskurinvaihtojärjestelmä (ja paljon muuta), joka karsii ylimääräiset pois listasta kun kirjoitat osan puskurinnimestä. Tutuilla hakunapeilla voi pyörittää listaa, jos se on helpompaa kuin nimen tarkentaminen edelleen. Lisäksi lista on oletuksena järjestelty niin, että viimeksi käytetyt puskurit ovat listan kärjessä. Yleensä muutama näppäimenpainallus riittää oikean puskurin kaivamiseen, vaikka niitä olisi auki kymmeniä tai satoja. Muitakin apuvälineitä puskureiden hallintaan löytyy.

Periaatteessa vastaavankaltaisen valintasysteemin voisi ikkunamanageriin rakentaa, mutta wm ei otsikon lisäksi juuri muuta oleennaista tietoa ikkunoista irti saa (ellei sitten sovellusta erikseen suunnitella niin, mutta ikkunamanagerille pitäisi joka tapauksessa koodata ko. sovellusta ymmärtävä vastakappale). Myös erikoisikkunat (editorin loki, ulkoisista prosesseista automaattisesti kerätty uloste, ohjeet, täydennyslistat) ovat wm:lle tuntemattomia.

Toinen vaihtoehto on tietysti palata siihen perinteiseen malliin, että editorissa on vain yksi puskuri auki kerrallaan, ja tarvittaessa avataan toinen instanssi tai toinen tiedosto vanhassa instanssissa. Zsh:n täydennysominaisuudet vertaansa vailla, mutta silti koen Emacsissa idolla hoidetun puskurinhallinnan kätevämmäksi. Progon mainitsemat kaikkialla sessiossa käytettävät rekisterit ovat kans todella hieno asia.

Tilettävä ikkunamanageri on hieno asia (omassa käytössä xmonad, stumpwm, nyt dwm) ja periaatteessa olen sen kannalla, että ikkunamanageri tosiaan pitää huolta ikkunoista. Uzbl:ia suunnitellessa tuosta paljon puhuttiin, ja tiletysleiskojakin mietittiin. Selaimen kanssa systeemi toimii kohtalaisen helposti: otsikko riittää valintakriteeriksi, erikoisikkunoita ei ole, eikä tabeja/ikkunoita tarvitse järjestellä tärkeyden mukaan (eli ei ole niin usein tarvetta toistuvasti hyppiä tiettyjen ikkunoiden välillä, toisin kuin koodatessa). En vaan usko, että kannattaa ikkunamanageria yksittäisten sovelluksien vuoksi laajentaa niin paljon kuin luullakseni olisi tarve, jotta päästäisiin editoreiden sisäisen puskurinhallinnan tasolle.

lainaus:

lainaus:

Irkkaan Emacsilla. Kirjoitan Emacsilla. Toisinaan käytän Emacsia shellinä ja web-selaimena. Tutut näppäinyhdistelmät ja komennot ovat siis jatkuvasti saatavilla. Toinen vaihtoehto olisi käyttää kaikkeen erikseen kyhättyä ohjelmistoa, mutta silloin jää aina jotain kirjoittelulle, navigoinnille, ym. oleennaista toiminnallisuutta puuttumaan – ellen sitten ota osaa ko. softan kehityksessä. Mutta mitä turhaan keksimään pyörää uudestaan?

Makunsa kullakin, mutta minä en koe menettäväni mitään siinä, että irkkaan irssillä, kirjoitan vi:llä, terminaaliemulaattorina käytän xtermiä ja webbiä selaan operalla.

Lähinnä siis oli tarkoitus selventää miksi "kaikki" halutaan välttämättä tehdä muka unix-filosofian vastaisesti "yhdellä" ohjelmalla (Emacsin voi myös käsittää erikoistuneeksi frameworkiksi, jonka päällä ajetaan sovelluksia). Iso liuta monessa sovelluksessa tarvittuja ominaisuuksia löytyy valmiiksi ja hyvin testattuna (nyt joku mainitsee kirjastot, mutta sanon, että tällaisen käyttöliittymän paketointi kirjastoksi ei ole niin yksinkertaista), eikä niiden hyödyntämiseksi tarvitse kirjoittaa riviäkään koodia. Käyttäjän preferenssit ja tutut komennot & näppäinyhdistelmät ovat käytettävissä jokaisessa sovelluksessa. Ei siis tarvitse koskaan odotella josko joku kerkeäisi sisällyttää (ja testata ja korjata uudet bugit) jo keksityn ominaisuuden sovellukseen X.

Jos irssi ja kiljoona muuta sovellusta toimii, niin mikäs siinä. Itse irkkasin irssillä yli viisi vuotta, mutta Emacsiin vaihdettuani alkoivat irssin Emacs-tyyliset mutta "not quite" -bindit ärsyttää. Lisääntyvässä määrin painelin näppäinyhdistelmiä jotka toimivat Emacsissa mutta eivät sitten toimikaan irssissä. Lopulta vaihdoin ERCiin. (Täytyy myös lisätä, että minusta irssin laajentaminen perlillä on *todella* kankeaa; ks. adv_windowlist.pl)

lainaus:

HAVE YOU READ YOUR SICP TODAY? Lisp-perhe on erittäin mukava niinkuin muutenkin funktionaalinen ohjelmointi. Nykyään minulla funktionaaliseksi kieleksi suurimmalti osin vaihtunut Haskell. :$

Haskellilla aloitin funktionaalisen ohjelmoinnin sillon kun xmonadista kiinnostuin. Lisp tuli myöhemmin. SICP <3.

progo kirjoitti:

Kyllä ymmärrän senkin argumentin hyvin, että unix-filosofisesti ajateltuna vain "vi" on oikeaoppisesti rakennettu tekemään tekstin editoimista ja vain sitä, mahdollisimman tehokkaalla tavalla.

"Do one thing, and do it well" -- tätä usein hoetaan, mutta minusta tärkein seuraa vasta perästä: "Write programs to work together. Write programs to handle text streams, because that is a universal interface." Yhden asian hyvin tekemisessä on se idea, että ko. tekelettä voi helposti käyttää osana suurempaa kokonaisuutta; ylimääräiset ominaisuudet eivät tule tielle, koska niitä ei ole. Ei siis tarvitse keksiä pyörää uudelleen kun joku on kerran kirjoittanut sovelluksen yhden asian hoitamiseen.

Interaktiiviset käyttöliittymät jäävät lähes väkisin tämän ulkopuolelle, ne kun ovat usein niin äärettömän tehtäväkeskeisiä. Toinen juttu niissä on se, että ne yhdistävät ihmisen tarvitsemia tehtäviä, joita tapaa olla monia. Tekstin (tai koodin) editointi ei siis ole yksiselitteisesti määritelty tehtävä, jonka voisi noin vain paketoida yhdeksi yhden asian tekeväksi sovellukseksi (ellei ed sitten ole jo se, kuten aiemmin vihjasin). Ja vaikka puhutaan editoinnista, voi olla kyse myös paljon muusta. Sananvalinta on jäänyt.

Sekä Vimiä että Emacsia voi käyttää skripteissä batch-moodissa, mutta harva haluaa (joskus käytän vimiä, siinä on sediä rikkaampi setti regex-hiluja). Interaktiivista käyttöliittymää taasen ei voi putkettaa. Kumpikaan editori ei ole yhteen asiaan keskittyvä palapelin pala, jolla olisi universaali tekstivirtakäyttöliittymä. Ei edes elitistien nvi >:). Tekstieditori on ennemminkin sovellus, joka kokoaa ja valitsee tarkoitukseen sopivan pipelinen. Mutta interaktiivisuuden myötä vaaditaan hieman muutakin.

Emacs ei ole Unix-filosofian antiteesi. Ei Emacs tee kaikkea, vaan Emacsilla voi tehdä, jos koodin kirjoittaa (tai jos joku muu sen on valmiiksi kirjoittanut). Taustalla toimii tehokas ohjelmointikieli. Emacs myös nöyränä hyödyntää ulkoisia sovelluksia (grep, ls, aspell, ym.). Vimissä on nykyään oma grep, ja taisipa reilu vuosi sitten tulla oma spellcheckerikin?

Mutta onko se enää tekstieditori?

jcd3nton kirjoitti:

Sekä Vimiä että Emacsia voi käyttää skripteissä batch-moodissa, mutta harva haluaa (joskus käytän vimiä, siinä on sediä rikkaampi setti regex-hiluja). Interaktiivista käyttöliittymää taasen ei voi putkettaa. Kumpikaan editori ei ole yhteen asiaan keskittyvä palapelin pala, jolla olisi universaali tekstivirtakäyttöliittymä. Ei edes elitistien nvi >:). Tekstieditori on ennemminkin sovellus, joka kokoaa ja valitsee tarkoitukseen sopivan pipelinen. Mutta interaktiivisuuden myötä vaaditaan hieman muutakin.

Emacs ei ole Unix-filosofian antiteesi. Ei Emacs tee kaikkea, vaan Emacsilla voi tehdä, jos koodin kirjoittaa (tai jos joku muu sen on valmiiksi kirjoittanut). Taustalla toimii tehokas ohjelmointikieli. Emacs myös nöyränä hyödyntää ulkoisia sovelluksia (grep, ls, aspell, ym.). Vimissä on nykyään oma grep, ja taisipa reilu vuosi sitten tulla oma spellcheckerikin?

Hyvää tekstiä kaikin puolin. Halusin vain vielä tarkentaa, että en minäkään Vimiä pidä unix-filosofian perikuvana, koska se syö kaikenlaista sisäänsä. Viittasin aiemmissa juuri siihen alkuperäiseen vi-toteutukseen, joka on aika no-nonsense. Vimissä on pelit ja lekkeet sisäänrakennettuna; kielioppitarkistus oli kaiketi jonkun aikaa aspellille ulkoistettu toiminto, mutta sitten Bram päätti kirjoittaa omansa. Eli aika vähän tuo Vimkään pyrkii siihen unix-filosofian tukemiseen. Ei se olekaan sellainen show stopper minulle, kuten aiemmin jo ilmaisinkin.

progo kirjoitti:

Vimin omien puskureiden käytössä on se ilmeinen etu, että ohjelman omia rekistereitä voi käyttää leikkailuun ja liimailuun. Vim toki tukee X:n leikepöytääkin, mutta siinä on ylimääräinen rekisterinvalinta.

Onkos nää rekisterit siis buffereita?

jcd3nton kirjoitti:

Koitin selventää tuota, kun sanoin, että editorilla on ymmärrys buffereiden sisällöstä (toisin kuin ikkunamanagerilla). -- Muitakin apuvälineitä puskureiden hallintaan löytyy.

Emacs ja buffereiden käyttö ties mihin on kyllä tuttua.

lainaus:

Periaatteessa vastaavankaltaisen valintasysteemin voisi ikkunamanageriin rakentaa, mutta wm ei otsikon lisäksi juuri muuta oleennaista tietoa ikkunoista irti saa (ellei sitten sovellusta erikseen suunnitella niin, mutta ikkunamanagerille pitäisi joka tapauksessa koodata ko. sovellusta ymmärtävä vastakappale).

WM_CLASS toimii paremmin ohjelman tunnistamiseen kuin WM_NAME. Joka tapauksessa infoa on sellaisenaan liian vähän.

lainaus:

En vaan usko, että kannattaa ikkunamanageria yksittäisten sovelluksien vuoksi laajentaa niin paljon kuin luullakseni olisi tarve, jotta päästäisiin editoreiden sisäisen puskurinhallinnan tasolle.

Aika turha ominaisuus, kun miettii työmäärää, minkä asia vaatisi.

lainaus:

Lähinnä siis oli tarkoitus selventää miksi "kaikki" halutaan välttämättä tehdä muka unix-filosofian vastaisesti "yhdellä" ohjelmalla (Emacsin voi myös käsittää erikoistuneeksi frameworkiksi, jonka päällä ajetaan sovelluksia). -- sovellukseen X.

Ymmärrän kyllä tämän kannan hyvin.

lainaus:

(Täytyy myös lisätä, että minusta irssin laajentaminen perlillä on *todella* kankeaa; ks. adv_windowlist.pl)

irssin perl API on kyllä aika kuraa ja parhaat dokkarit on irssin sorsat.

lainaus:

progo kirjoitti:

Kyllä ymmärrän senkin argumentin hyvin, että unix-filosofisesti ajateltuna vain "vi" on oikeaoppisesti rakennettu tekemään tekstin editoimista ja vain sitä, mahdollisimman tehokkaalla tavalla.

"Do one thing, and do it well" -- tätä usein hoetaan, mutta minusta tärkein seuraa vasta perästä: "Write programs to work together. Write programs to handle text streams, because that is a universal interface." Yhden asian hyvin tekemisessä on se idea, että ko. tekelettä voi helposti käyttää osana suurempaa kokonaisuutta; ylimääräiset ominaisuudet eivät tule tielle, koska niitä ei ole. Ei siis tarvitse keksiä pyörää uudelleen kun joku on kerran kirjoittanut sovelluksen yhden asian hoitamiseen.

Tuo loppuosa pitää sisällään suuren osan UNIX-filosofian ideasta. Pelkän UNIX-filosofian väläyttäminen sellaisenaan on aika ontuvaa minusta, IMO asia ja ympäristö pitäisi käydä kunnolla lävitse ja perustella kunnolla, miksi siinä tilanteessa tehty ratkaisu on paras, eikä heittää pelkkää UNIX-korttia.

lainaus:

Sekä Vimiä että Emacsia voi käyttää skripteissä batch-moodissa, mutta harva haluaa (joskus käytän vimiä, siinä on sediä rikkaampi setti regex-hiluja). Interaktiivista käyttöliittymää taasen ei voi putkettaa. Kumpikaan editori ei ole yhteen asiaan keskittyvä palapelin pala, jolla olisi universaali tekstivirtakäyttöliittymä. Ei edes elitistien nvi >:). Tekstieditori on ennemminkin sovellus, joka kokoaa ja valitsee tarkoitukseen sopivan pipelinen. Mutta interaktiivisuuden myötä vaaditaan hieman muutakin.

Batch mode (-s) on ex:n standardoitu ominaisuus.

fronty kirjoitti:

progo kirjoitti:

Vimin omien puskureiden käytössä on se ilmeinen etu, että ohjelman omia rekistereitä voi käyttää leikkailuun ja liimailuun. Vim toki tukee X:n leikepöytääkin, mutta siinä on ylimääräinen rekisterinvalinta.

Onkos nää rekisterit siis buffereita?

Rekisterit ovat se "leikepöytä" copy/kill/paste -ketjuun. Vimin tapauksessa myös makroihin sun muuhun.

lainaus:

Tuo loppuosa pitää sisällään suuren osan UNIX-filosofian ideasta. Pelkän UNIX-filosofian väläyttäminen sellaisenaan on aika ontuvaa minusta, IMO asia ja ympäristö pitäisi käydä kunnolla lävitse ja perustella kunnolla, miksi siinä tilanteessa tehty ratkaisu on paras, eikä heittää pelkkää UNIX-korttia.

Minusta pelkkä "kortin väläyttäminen" päästää jo pitkälle, siinäkin määrin, että sitä kannattaa kokeilla ainakin alustavasti toteuttaa orjallisesti. Todellakin vasta sitten kun kaikki mahdollinen on tehty, voi kokeilla erikoistaa.

progo kirjoitti:

Rekisterit ovat se "leikepöytä" copy/kill/paste -ketjuun. Vimin tapauksessa myös makroihin sun muuhun.

Mitä nyt googletin, niin ilmeisesti nuo rekisterit siis ovat buffereita eri nimellä. Esim. "5Y kopioi rivin bufferiin viisi.

Näinhän tuo todella näyttää olevan, alkuperäisen vi:n tapauksessa. Vimissä taas otettiin ehkä hämäävähkösti bufferin käsite käyttöön tarkoittamaan kutakin avointa tiedostoa. Aluksi hämäännyin vähän itsekin tästä, mutta nyt näemmä teoksessa "Learning the vi Editor" seisoo asia selvästi:

"your last deletion is saved in a buffer---you can access the contents of that buffer --- with the put command (p or P)".

Tosin numeroidut puskurit on varattu näille poistoille sellaisenaan, ja niihin voi siten viitata suorasti vain "pastetettaessa", esim "2p palauttaa toiseksi viimeisen poiston. Aakkoset a-z ovat sitten käyttäjän omille, nimetyille leikkeille.

Tämä siis vi:ssä, ja luultavasti nvi:ssä. Vimissä näitä siis kutsutaankin rekistereiksi, josta se fraasi on minullekin tarttunut. Yhtenä vimin tarjoamista lisäherkuista juuri tähän asiaan mainittakoon se, että "puskuriin" voi tallentaa viittaamalla pieneen aakkoseen, ja tiettyyn "puskuriin" voi sitten lisätä uutta tavaraa käyttämällä isoa kirjainta.

Huh, kuten näkyy, minulla on melko innokas asenne tähän ohjelmaan. :)

Itse siirryin Vim -> Emacs kun en jaksanut näppäinten mäppäystä tuunata. Qwertyllä vim on ihan passeli.

Emacsissa tykkään siitä että näppäinkomennot ovat yhtä syvältä oli näppäinasettelu mikä tahansa :)

Itsekkin pitäisi keksiä irssin korvike kun siinä ei kaikki Emacs komennot toimi. ERC kokeilin mutta se putoili servulta koko ajan niin pysyttelen edelleen irssi + tmux kombossa.

Emacs Lispin kun saisi korvattua schemellä ja saisi hieman säikeistetymmän emacsista niin kelpaisi. Guilea ne taitaa yrittää Emacsiin saattaa mutta saa nähä tuleeko siitä mitää.

Zmyrgel kirjoitti:

Itsekkin pitäisi keksiä irssin korvike kun siinä ei kaikki Emacs komennot toimi. ERC kokeilin mutta se putoili servulta koko ajan niin pysyttelen edelleen irssi + tmux kombossa.

Itse olen tässä koittanut etsiskellä passiivisesti irssille korvaajaa lähemmäksi vimiä (ja VimIRC on ollut hajalla viimeiset 4 vuotta) -- havaitsin parhaaksi ratkaisuksi lopettaa koko irkkaamisen kun ei niin epäkäytännöllisellä softalla tee mitään :/

Melkein pääsin kyllä sellaiseen toteutukseen asti, että pelkällä perlillä sai irssiin alkeellisen modaalisuuden, ja mahdollisuuden surffailla kanavia ilman modifierejä, mutta se ontui sen verran pahasti, ettei tullut mitään.