VIM, azaz így váltam pair programmingra teljesen alkalmatlanná

FOSDEM-en sétálgatva kiszúrtam egy könyvet, aminek elég undorítóan bulváros alcíme volt.

Practical Vim: Edit Text at the Speed of Thought

Aha, meg fogyjon le két hét alatt, meg 10 tuti tipp a házasság megmentésére. Aztán felfigyeltem a szerzőre. Drew Neil. Hm... Ez a vimcast.org vloggere. Előszó: Tim Pope. Hát ő meg a legelismertebb plugin-szerző.

Te jó ég, ezek az emberek miért adnák a fejüket ilyesmihez?! Nosza rajta, csak 30 dolcsi, megvettem. Végigmentem rajta kb. egy hét alatt, majd még egyszer, majd bele-beleolvasgattam helyenként. Ez volt az a pont, amikor ~10 évnyi vimezgetés, alkalomszerű használat után megtanultam úgy mélységében, átláttam, leegyszerűsödött az egész. Beszéli a vim a nyelvemet, átlagosan 3-4-szer, néha akár 50-szer (helló, makrók) gyorsabban editálok fájlokat, mint régen.

És itt a probléma. Nem csak a régi énemnél vagyok gyorsabb, de mindenki másnál is a környezetemben. Eleinte még türelemmel bírtam, amint egy inifájlban soronként betett a kolléga egy kommentet. Kicsit nehezebben, amikor egy másik html-t próbált meg szerkeszteni úgy, hogy egy teljes <table> taget a delete gombra való ~10másodperces támaszkodással törölt ki. De ott már majdnem felálltam, amikor a harmadik a fájl végén levő x.x.x.199-es IP címet 200-ra növelte több másodpercnyi egerészgetés, görgetgetés, meg belekattintás, meg backspacebackspacebackspacekettőnullanulla után, ahelyett, hogy egy G$Ctrl-A -t nyomott volna bazmeganyád.

Egy tmux-os vim-es pairprogramming session közben meg vagy magyarázom a telefonba, hogy most mit csinálok, vagy a kollégának fogalma sincs mi történik. Az előbbi lassú, az utóbbi idegesítő. Elfogyott a türelmem. Ha egyszer lehet ezt gyorsan is csinálni, akkor mér baszakodunk?

A tíz sor commentet beteszem 10gcc-vel, mert 10 sor kommentet akarok. A negyvensoros <table> taget kiszedem dat-vel, mert a taget akarom deletézni. Azt a kurva inkrementálást meg elvégzem inkrementálás operátorral, nem pedig kitörlök meg beírok számokat. A legtöbb embert lassítja az editora. Mert nem azt csinálja az editorban, amit szeretne elérni. A legtöbb ember számokat töröl, meg visszatesz, pedig inkrementálni akar. Nem tűnik túl hatékonynak.

A tanulság az, hogy ne ítéljek elsőre. Bár még mindig bulvárosnak hangzik a könyv címe, de tény, hogy a gondolat sebességével sikerül néha editálni.

( uid_720 | 2015. 07. 24., p – 21:18 )

Én a múltkor 2015. 07. 01.-nél a 07-re nyomtam CTRL-A-t, és mosolyogtam:
2015. 010. 01. lett :-)

Fuszenecker Róbert

( BaT | 2015. 07. 24., p – 21:37 )

Programkód esetén a kijelöl + comment shortcut szerintem felveszi a versenyt a te módszereddel, főleg ha 10+ sorról beszélünk (nem látszik ránézésre pontosan hány sorról van szó). Tag kitörlésre is biztosan van értelmes shortcut (bár fejből egyik ide-ben se tudom hogy kell), számokat inkrementálni meg nem nagyon akarsz mert programkódban legfeljebb a 0-nak és 1-nek van helye. :)

Akkor ajánlom neked is a könyvet. Nem veszi fel a versenyt.

Relative sorszámmal _egyből_ látod, hogy az bizony hány sor. Gondolj bele. Te nem kijelölgetni akarsz, etc. Te kikommentezni akarsz. Akkor ne kijelölgess. Ránézel, 10gcc, vagy ha nincs kedved fejben a 9-hez egyet hozzáadni, akkor gc9j. (btw. ez nem a legjobb példa, mivel plugin adja a gc operátort.)

Szerk., persze hogy nem tudod, hogy melyik shortcut. Mert valószínűleg az editorodnak nincs "nyelve". Vimben ezt mondod: "Delete A(ll) Tag". Vagy meg akarod tartani magát a <table>&lt/table> taget? OK! "Delete Inner Tag"! dit. Szót akarsz? daw. Egész mondatot? das. A függvény nevét a zárójelig? dt(. Good luck, hogy akár tized ilyen gyorsan megoldd ezt egy nem modal editorban.

Hidd el, én évekig bénázntam intellijben-eclipse-ben etc. Összehasonlíthatatlanul lassabb mint a modal editing. Próbáld ki te is.

Ahogy elnézem a relatív sorszámokat eleve egy külső plugin adja, arról eddig nem volt szó. :)

Egyébként nem teljesen értek egyet. Pl. idea refactoring extract/inline:

  • Extract variable: ctrl + alt + v
  • Extract constant: ctrl + alt + c
  • Extract method: ctrl + alt + m
  • Inline* / Not extracted: ctrl + alt + n

*: oké, ez elég erőltetett

Ha értelmesen vannak kitalálva a shortcutok, könnyen berögződnek, utána már gyors használni azokat. Ha meg még nem rögződött be, vimben sem jut eszedbe könnyebben, hogy mire van rövidítve az adott action.

Nem külső plugin. :help relativenumber

ctrl, alt, és a többi. Az Emacs kreátora RSI-vel küzd, már nem is tud gépeni rendesen. Miért használnál ennyi módosítót, amikor az angol abc 26 betűjét is használhatnád?

Tényleg, próbáld meg a modal editinget. Én próbáltam mindkettőt, egyértelmű melyik a nyerő. Neked sajnos nincs még összehasonlítási alapod. De ezen könnyen változtathatsz :-)

> vimben sem jut eszedbe könnyebben, hogy mire van rövidítve az adott action.

daw Delete All Word
ci" Change Inner quotes
yit Yank Inner Tag

Pont az a lényege a vim nyelvnek, hogy nem kell megtanulni a "shortcutocat". Nyelvtanuláskor sem mondatokat tanulsz, hanem szavakat, szerkezeteket, amikből építkezel. kapásból a fenti három példából tudsz csinálni 3*2*3 = 18 különböző kombinációt. Aztán kitalálod, hogy ha a ci" működik, akkor valószínűleg a ci' is. Illetve a ci[, ci(, ci{, etc. Hopp, máris 3*2*7=42-nél járunk. Etc.

Oké, tehát azt mondod, hogy annyira intuitív, hogy anélkül, hogy dokumentációt olvasgatnék, meg tudom mondani, hogy pl. hogy kommentelek ki egy html taget pusztán abból, hogy tudom hogy hogyan kommentelek ki egy sort, meg hogy hogyan törlök egy html taget? (Ez így a fentiek alapján mondjuk gcat lenne, na ez működik?)

Pontosan. Igen, gcat. Gratulálok, már megérteted magad a vim nyelven. :-)

Szerk.: De még egyszer mondom, a gc-s példa nem volt szép tőlem, mert az pont plugin. A legtöbb plugin viszont "good citizen". az "at", "it" része a commandnak ún. "text object", és a pluginek általában együttműködnek ezekkel a text objectekkel. Például amit pythonnal használok (ahol ugye az indent a block), ott egy dii és már töröltem is az adott "blokkot". Ez is egy jól viselkedő pluginnek köszönető, ami épp egy újfajta text objectet definiál (az indent text objectet)

( Nyosigomboc v | 2015. 07. 24., p – 22:00 )

Szerintem szerezz be magad melle pair-nek egy olyan kollegat, aki ismeri a VIM-et, es olvasta a konyvet. Azzal mindenki jol jar.

Egyebkent mit ajanlanal vim kezdesre? Ez a konyv milyen szintrol indul? Illetve a sima vim-et erdemes meg elkezdeni, vagy a neovim-et? ( http://hup.hu/node/141256 )

--
The Bible is the longest set of Terms & Conditions ever.
So many people agree with it without knowing why.

Kösz a tippet az új kolléga beszerzéséről. Valamiért másokat itt nem érdekel a hatékony szerkesztés. :-(

Kezdésre ajánlom ezt a könyvet. Azért is haladtam gyorsan vele, mert egy részével már tisztában voltam, szóval valószínűleg kezdőknek is jó.

A sima vim-et azért érdemes még elkezdeni, mert ahova be-ssh-zol, ott még az lesz. Egyébiránt leginkább IDE-jellegű szolgáltatásokat ad a neovim, szóval editálásra teljesen mindegy, melyiket használod.

Illetve vedd figyelembe, hogy ez szándékosan "csak" egy editor. IDE-jellegű szolgáltatásokat ne keress (vagy csak pluginekben). A zürichi google-er haverok egész teamjei eclimmel használják, így teljes Java+Android támogatásuk van.

De bizony. Ugyanis két lehetőség van:
- van vim alaptelepítésben.
- nincs vim alaptelepítésben (általában vi még akkor is). Ekkor Neovimet nem tud feltenni egyszerűen repóból, míg vimet igen.

Ubuntu és RHEL/CentOS szervereken mozgom, neovim-et max. külső repóból tudnék telepíteni, vim-et viszont egyszerűen egy yum/apt-get installal, ezért meg is teszem. Tehát a kérdezőnek válaszolva neovim és vim közül azért érdemes még vimmel elkezdeni, mert ahova be-ssh-zik, ott még az lesz.

Más kérdés, mi van akkor ha még mainframe-eken él az illető, akkor valószínűleg nem a neovim/vim a választás a legnagyobb gondja.

OK. Akkor az értetlenek kedvéért: vim-et egyszerűbben tud magának varázsolni az ember jelenleg, mint neovimet, ezért érdemes vimmel kezdeni.

Erre is fel lehet sorolni vagy 5 cornercase-t, de a tényen nem változtat, hogy a vim több tíz éve elterjedt, míg a neovim most van feljövőben, és (hasra csapva) 98%-ban kompatibilis vele.

Olyannyira van Solarisra vim, hogy pont az ilyesmik a neovim fejlesztők legnagyobb baja: mindenféle elavult, vagy nem használt, vagy már rég nem is létező hardver támogatása miatt van spagetti a vim forráskódjában. Továbbá sok pluginnél is lehet látni, hogy támogatnak Solarist.

De mielőtt a másik négy corner case is feljönne, AFAIK Amigára is van vim, és OS/2-re is (asszem ez utóbbi miatti spagetti lassítja nagyon a vimben az inputot)

> Nem mindenki csak GNU/Linuxot lát ám :)
Nem is mondtam. Azt mondtam, hogy én főleg ezekkel foglalkozom, és azt, hogy neovim és vim közül _bárhol_ valószínűleg vimmel fog találkozni.

http://vim.wikia.com/wiki/Installing_on_Solaris
Ezért nincs Solarison csak úgy vim. Persze, támogatott a rendszer, de ez nem azt jelenti, hogy random bejelentkezek egy Solaris szerverre (ezt napi szinten csinálom melóban) és lesz vim. Nem, nem lesz. Míg egy GNU rendszeren előbb lesz vim és vi, mint csak vi.

( bzs v | 2015. 07. 26., v – 19:17 )

ELTE-n a C mellett a vi-t tanitottak, senki sem ertette miert. Engem erdekelt, mert allitolag pont a gepirast ismeroknek talaltak ki, minden mas valoban lassit. Csak volt egy bokkeno. Nem szerettem, mert az mcedit jobban bejott, abban voltam mar gyors. Ha meg brutalis dolgot kell csinalni, akkor sed, cat, awk, grep..
Rendben, hogy a vi es a vim utolerhetetlen, de kevesen szanjak ra az idot, hasonlokeppen a gyors- es gepiras rendes megtanulasara.

---
--- A gond akkor van, ha látszólag minden működik. ---
---

( sunmao v | 2015. 07. 27., h – 17:08 )

Nem tudom, hogy dev vagy-e vagy csak adott esetekben foglalkozol kód editálással, de szerintem a szoftverfejlesztés legnagyobb részét nem a (be)gépelés veszi el.
Ha neked a fejlesztésnél a fájl szerkesztése és nem a probléma helyes megoldás a bottleneck, akkor irigyellek! :)

De az is lehet, hogy csak szimplán eltérő célú/levelű kódot írunk.

Senki nem mondta, hogy ez a bottleneck. Nem a begepeles, hanem a tervezes, kod olvasasa. Es csak a vegen az editalas. Aztan a begepeles. Az itt leirt sok pelda is editalasra, torlesre, atirasra ad peldat. Olvasd at a topikot.

Mostanaban sokat editalok konfigfajlokat. Itt aztan tenyleg a szerkesztes gyorsasaga segit.

De tegyuk fel, hogy az editalas kell a legkevesbe. Akkor is, miert ne csinaljuk gyorsan?

( drobert82 | 2015. 08. 04., k – 10:32 )

Nos, megvettük a könyvet cégre.
Én is csupa jó véleménnyel vagyok :)

Szóval köszi a tippet!