Jake triky? http://www.nano-editor.org/y uz jste o nejakem slysela? http://www.nano-editor.org/
BTW, fuj. Radsi mcedit.
Par rozdilu tam je, hlavne v makrech, ale to neni az tak kriticke. Spis jsem chtel rict, ze u POSIXovych systemu se ocekava, ze vi nebo vim(compatible) bude nainstalovan vzdy, takze napriklad admin bude mit jistotu, ze nemusi zapasit s 'ed'em ;-) To, ze je dnes na vetsine Linuxovych distribuci nano spis souvisi s RMS (IMHO).
:D :D
To ano :)
A navic, kdyz si spustim nano, vse dulezite (~ ovladani) mam porad dole na ocich, popr. F1 to jisti :)
Neznam 'vim', ktery mozna ma x dalsich vyhod oproti nano, ale co si pamatuju, to ssssiiilleeeneeee ovladani - pohyb kurzoru, vymaz atd. atd., jeste dnes se z toho budim ze spani :D :D
Taky jsem to dřív nemoh pochopit, co je na tom tak skvělýho, ale pak jsem si k tomu jednou sednul, otevřel si manuál a za chvíli bylo jasno. Vim je skutečně super věc. Jsem rád, že ho už dokážu používat, protože oproti Nanu je ve všech ohledech lepší (až na tu počáteční složitost).
Ja jsem brachu dotlacil k Vimu pres Easy Vim (evim), ktery se snazi tvarit jako textovy editor bez rezimu (do prikazoveho rezimu se musi pres CTRL+O), namapuji se bezne klavesove zkratky pro praci s bloky, F1 pro napovedu atd.
Takze pro lidi, co cely den nepracuji s ciste textovymi soubory se nabizi velka cast funkcnosti Vimu a lepe zkousnutelne ovladani.
Ono to chce zkusit. Samozrejme, kdyz jsem se driv (kdyz jsem ho neznal) dostal do vimu, tak jedinej zpusob ukonceni byl ctrl-z (suspend) a kill -9.
Clovek se musi vim aspon trosku naucit, aby v tom dokazal pracovat. Samozrejme, lepsi je zjistit si vsechny moznosti, protoze do te doby si clovek bude myslet, proc to je tak blby, ze se musi prepinat mezi rezimy. Vetsina lidi ve vimu mazou text z insert modu, idkyz jde snadno (obvykle rychleji a jednoduseji) z normal modu, napr. smazat jedno slovo, ve kterem je kurzor uprostred - neznali najedou kurzorem na zacatek slova, prepnou do insert modu a pomoci Delete smazou jednotlive znaky. Vimak proste v normal modu zada "diw" (bez uvozovek) - to znamena totiz "d" delete "i" inner "w" word - a slovo je zmazany - neresim zacatek slova, delku slova, proste mazu slovo. A takovych figlu je spousta. Ono to neni silene, ono to je logicke, spousta zkratek je odvozenych z nazvu prikazu, spousta akci jde delat zaroven z vice ruznych modu, napr. vlozit text z registru A v insert modu pomoci CTRL-R + A, z normal modu '"ap' (tady jsou uvozovky dulezite) a z command modu ":put a", takze ve finale clovek pracuje o dost rychleji nez s jinym editorem (mozna s emacsem se pracuje stejne rychle).
Osobne jsem se jednou rozhodoval, jaky editor budu v linuxu pouzivat (v DOSu jsem pouzival QEdit). Rikal jsem si, ze zkusim vim a emacs. Zacal jsem vimem a skoncil jsem u nej:-) Koukal jsem i na emacs, ale ty klavesovy zkratky CTRL-neco1 + CTRL-neco2 bylo na me moc. Vim mi prijde logictejsi.
Doporucuju projit si ten tutorial ve vimu. A pak si procist seznam vsechn prikazu, jen pro prehled - nemusis se je ucit na zpamet, :help ti vzdycky poradi:-)
No taaaak !
Napriklad pri vyvijani pamatovo narocnejsich aplikacii sa kazde mega usetrenej pamate hodi. Vim je presne pre taketo pripady vhodny, lebo graficke ide su pazrave.(Ano urcite existuju obskurne a nenarocne ide, no vim je pre mna viac po ruke).
Alebo su situacie, ked treba rychlo fixnut deploynuty kod a bolo by treba u seba rozbehavat cele prostredie. Pouzije sa vzdialene vim a je vystarane.
Netreba nutne zhadzovat. Ako primarne ide by som vim nebral, ale je to "svajciarsky nozik" vhodny na riesenie osemetnych situacii.
Hehe, u nas jeden kolega napsal, ze potrebuje na programovani stanici s 8GB RAM a rychlejsim SATA (tusim chtel SATA3, protoze SATA2 byla moc pomala). Pouziva IDEA na programovani v Jave:-)
Na druhou stranu. Prisel kolega admin, tak rikam, ze mu staci do 4GB RAM normalni malej desktop, jako mam ja. Dostal 12GB RAM protoze nic horsi na sklade nebylo:-)
<flame>
To, ze jste se zatim nesetkal s nutnosti pouzit *skutecny* editor, ktery napriklad inteligentne pracuje se zalohami i na nestabilnich systemech (kde muze kazdou chvili kleknout jadro nebo nejaky modul, takze primitivni tvorba kopii souboru neni tou spravnou cestou) a dokaze bez problemu editovat i 20MB XML soubory, neznamena, ze takovi vyvojari neexistuji :-)
IDE je samozrejme fajn, ale pouze v pripadech, kdy mate k dispozici stabilni a vymazlene prostredi, ktere pro vas nekdo pripravil, mj.i ve Vimu ;-)
</flame>
Technická: Kotvy v článcích nefungují.
Jinak díky za perfektní článek. Některé věci jsem věděl, ale zapomněl, některé jsem ani netušil. To znamená, že se k článku budu často vracet.
K obrázku číslo 15: Evidentně jde o tabulku klíčových slov jazyka BASIC z nějakého osmibitu. Je tam vidět, že řetězce jsou namísto nulového byte ukončeny nastavením 7. bitu v posledním znaku. Tenhle princip se používal na ZX Spectru, ale Spectrum nemělo klíčové slovo DRAWTO. Z toho tipuji, že jde o ROMku s ATARI BASICem.
Nemáte nějaký tip na to jak zlepšit 3-way merge ve vimu? Když si pomocí vim -d base left right result otevřu čtyři panely, tak se v tom za chvíli nemůžu vyznat ...
Ještě horší je to když se přepínám mezi vertikálním a horizontálním pohledem, to se ještě pořadí panelů přehází.
Na přepínání používám tohle:
" Align split windows vertically
function! Vertical()
windo wincmd H
endfunction
com! -nargs=0 Vertical call Vertical()
" Align split windows horizontally
function! Horizontal()
windo wincmd K
endfunction
com! -nargs=0 Horizontal call Horizontal()
--
Vláďa
Naco si komplikujete zivot. Ak potrebujete tak robte dva rozne diffy "base a left" a "base a right". Ak potrebujete skutocny 3diff tak si ho potom vygenerujte cez diff3 a otvorte "base result" (vim podporuje priamo otvoranie diff-u ako druheho suboru). Nic ine nema vyznam. To o co sa pokusate lahko dosiahnete cez poslednu moznost. Naco by som konsolidoval "base left right" vsetko uvidim po diff3 a tam to skonsolidujem.
Naviac skusali ste uz nejaky version system? SVN, CVS, ... nebodaj GIT. To by ste si to s takymto pristupom asi hodili.
Taketo 3diff harakiri som pachal este ked som si robil vlastny "version system" respektive spajanie zdrojakov asi pred 15timi rokmi.
Pekný zrovna combo xxd a vim jsem potřeboval v minulé práci. :-) Kdysi jsem pracně sháněl tyhle informace.
Možná by stálo zato za to u VIMu ukázat jak se dá spojovat clipboardy - myslím tím KDE/GNOME clipboard, systémový - ten co používá střední tlačítko pro paste a ten VIMovský - do ktereho kopirujes např. přes CTRL-v-y. (Jakože možný námět pro pokračování v článcích o VIMu :-))
Možná se to tu už někdy řešilo, ale já to nezahlíd.
BTW Dobrý článěk!
Vo VIM-e mate 26 ci kolko clipboardov - kazde pismenko jeden. Ked pouzijete pri nacitani (yank) velke pismeno obsah sa do clipboardu prida (to co tam je zostane). No a GUI clipboard ma nazov + alebo *. Takze ak si nieco nacitate do Gnome clipboardu tak vo VIM-e to pastnete cez "+p a ak chcete nieco nacitat vo VIM-e do GNOME clipboardu tak pouzite napriklad na nacitanie aktualne celeho riadka "+yy
Potom mate k dispozicii este dalsi asi 12 specialnych registrov viac na :help registers
Skvělý článek, Pavle.
Jako dlouholetý uživatel Vimu bych měl dvě poznámky.
1) To, že nefunguje dobře scrollování při použití GVimu, mě dohání někdy k šílenství. Už několikrát jsem se pokusil o nějaké řešení, ale dodnes příkazy, které potřebuji scrollovat i nahoru, spouším v xtermu.
2) Ačkoli na Vim nedám dopoustit, diff je poměrně slabý a neodhaluje sofistikovanější změny. Používám tedy meld, který je o mnoho chytřejší. Možná je to jen věc nastavení velikosti prohladávacícho kontextu, ale i tak mi připadá vimácký diff docela nepřehledný.
Super, doufám že se seriál co nejvíc rozšíří i mimo jazyky C/C++ (skriptovací atd), případně vimscript, vytváření témat, syntaxí i pluginů.
Diky!
Je pravda, ze nekdy je s internim diffem problem, kdyz napriklad nenajde stejne funkce/metody, ktere jsou od sebe navzajem posunuty. Na prohlizeni vetsiny patchu me to vsak zatim stacilo, navic je tady porad externi diff -u :)
Uvidime, kam se serial bude ubirat (podle ohlasu), ale pluginy a vimscripty by nemel byt problem (barevna schemata taky ne).
Miluji VIM, je to opravdu genialni vec. Kdyz pisu jednoduchy HTML, TeX apod je to skvele. Neumim si ale predstavit, jak v tom delat na komercni urovni vyvoj. Jakmile delam na PHP projektu, oteviram okamzite Aptana Studio. VIM mam poladeny, ale na vyvoj, spravu verzi, praci s adresari, ftp prenosy apod je to jako dratem do oka ..
Ja jednu dobu stridal IDE->Vim->IDE a nakonec jsem i tak skoncil u Vim-u. V kombinaci s nekolika pluginy zustava (u me) neprekonan.
- xptemplate - http://vimeo.com/7868048 - zatim nejlepsi snippety, ktere jsem kdy potkal
- FuzzyFinder + ctags - hodne rychla prace s oteviranim souboru
- Fugitive - http://vimcasts.org/blog/2011/05/the-fugitive-series/ - super UI pro Git
- surround
...
Jeste je to mozne pomoci parametru primo pri otevirani souboru nebo jeho ukladani, viz http://vimdoc.sourceforge.net/htmldoc/editing.html#++enc
Chtel bych se zeptat. Pro javistu ktery nejakou dobu pouziva Eclipse, prinasi Vim neco navic ? Chapu ze Vim je light editor ktery spustim vsude, takze na mensi prace "na miste" se hodi, nicmene mohli byste mi Vim s klidnym srdcem dopourcit jako rovnocenou, plnohodnotnou nahradu za Eclipse ? Tusim ze Vim bude hodne sikovny pri editaci velkych souboru 100 Mb+ ovsem jako nahrada za ide typu Eclipse mi to nepripada. Ovsem necham se poucit od mazaku, kolega v praci soustavne pouziva Emacs jako primarni java IDE (coz jsem popravde take uplne nezkous).
Taky primárně používám IDE založená na Eclipse. Vim jsem několikrát zkusil a ta poznámka o rytí do hliněných destiček dokonale vystihuje moje dojmy. Rychle jsem zase zdrhal zpátky do toho přerostlého/lamerského/nenažraného, ale zato kurevsky pohodlého prostředí. Asi nemám dostatečné sklony k masochismu.
No pohodli v IDE to samozrejme nemuze nahradit. Nechapu proc si v dnesni dobe kompikovat zivot pri vyvoji pouzivanim VIM nebo Emacsu.
Nic proti tomu nemam, jen Eclipse nebo NetBeans jsou uplne jinde. A hardware uz neni problem jako byval jeste pred 7-8 lety mozna......
Je to spis pro nadsence, ale skutecnou efektivitu a vyhodu to podle mych zkusenosti proti normalnim IDE neprinese...spis naopak.
Co se tyce me, tak ja pri programovani vetsich projektu pouzivam IDE s pluginem pro vim. Ten mi castecne (ale opravdu pouze castecne) editor IDE vynahradí. Škoda jen, že většinou ty pluginy nejsou uplne dotahnute do konce. Pouzivam je ale hlavne kvuli pohybu ve zdrojovem kodu.
Pri programovani v Java a PHP vyuzivam v Netbeans plugin jVi.
Pro C++ s Qt zase pouzivam FakeVim.
Pro bezne programovani typu 99% kodu v Jave taky pouzivam Eclipse (nekdo Netbeans, Ideu atd. podle pozadavku a financnich moznosti), tam v podstate neni problem, az na trosku horsi moznosti editace, ktere vsak Eclipse vyvazuje moznostmi refaktoringu a hotswapu.
Ale pro vyvoj JDK - uznavam ze mozna trosku specificky - kde se mixuje Java, C++ a spousta nastroju okolo (Ant, Makefile/autotools, bashove skripty, perlovske skripty, desitky patchu - diffu, zdrojaky k manualovym strankam) se Eclipse nechyta, jednoduse proto, ze pro efektivni praci v Eclipse si musi toto prostredi cely projekt "privlastnit", vytvorit si interne vazby mezi tridami, postupne prekladat (jinak nenajde chyby) atd.
Sice vim, ze par lidi dokazalo projekt JDK nacpat do Netbeans, ale vetsinou to nebylo cele JDK, ale pouze jednotlive podprojekty.
Ja tedy pouzivam oba zpusoby a oba maji sve vyhody a zapory.
Jo navic se XML editor v Eclipse nechyta na velke soubory s desitkami mega - ja samozrejme vim, ze tyto obludy by nemely vubec vznikat, ale pokud clovek dostane od externi firmy celou DB vyexportovanou do XML :-( tak se s tim musi nejak poprat.
velmi dobre je i tohle: https://github.com/Rip-Rip/clang_complete
Moc děkuji za velmi pěkný článek. Určitě se k němu budu v budoucnu vracet a už teď se těším na další:-).
Jinak jsem chtěl ještě zmínit, že po tom co jsem začal s Vimem, jsem začal využívat jeho klávesových zkratek i v jiných aplikacích.
Kromě Vim pluginů využívaných v IDE (zmiňoval jsem výše) jsem nahodil ve Firefoxu plugin Vimperator a hudbu začal přehrávat v CMUSu, který částěčně zkratek z Vimu využívá.
Myslete si třeba, že jsem Vim-blázen :-), ale dost hodně mi to zrychlilo práci s počítačem...
Vim je jistě skvělý na občasné editování konfiguračních souborů, není-li zrovna k dispozici editor určený lidským uživatelům. (Vim je určený pro roboty-androidy.) Nicméně o IDE se nejedná ani náhodou.
Každý, kdo někdy v životě spustil Eclipse, neřkuli IntelliJ IDEA, by jistě dokázal vyjmenovat minimálně deset podstatných rozdílů mezi Vimem a IDE.
Auto-completion se znalostí typů, případně celých dlouhých konstruktů jazyka (uživatelé IntelliJ by mohli dlouze vyprávět, Eclipse taky něco z toho umí), je první podstatný rozdíl. Důkladné provázání s kompilátorem a debuggerem je dalším příkladem klíčové vlastnost IDE. Eclipse podporuje v případě C minimálně čtyři různé kompilátory a debuggery. Dál jmenujme například Ctrl+klik na identifikátorech, automatické generování Doxygen/JavaDoc tooltipů... To všechno je pro produktivitu práce naprosto zásadní, ale Vim nic takového nemá.
Nic proti Vimu, ale název „Textový editor Vim jako IDE“ je naprostý nesmysl, k němuž lze přirovnat snad jedině „Láhev od kořalky jako kladivo“. Některé věci zkrátka nejdou dohromady.
Samozřejmě, že Vim není sám o sobě žádné IDE, ale cílem článku je ukázat nástroje/pluginy/postupy, které vám zpřístupní/poskytnou chybějící funkcionalitu. Lidem, kteří, podobně jako vy, Vim nepoužívají či dokonce nesnáší, to moc nedá, ale pro někoho se díky tomu vim+nástroje okolo mohou stát zajímavou alternativou (stejně jako např. eclim.org).
Jinak chápu, že pro vás to je skutečně utrpení, ale zkuste si příště přečíst článek celý, pak si nebudete stěžovat na absenci ctrl+kliku na identifikátor (nebo kapitolu 5 špatně chápu?) :) Ostatně, tohle je zřejmě první díl seriálu. Čímž pádem předpokládám, že vámi vzpomínané provázání s kompilátorem či generování doxygenu bude v některém z dalších dílů, jelikož (a teď si radši sedněte) podle googlu to Vim "umí" taky :-o
btw když už jsme u toho flamu http://xkcd.com/378/
Pořád jsem ještě nepochopil, proč se vždycky najde nějaký chytrolín, který ke článku popisujícím vim a jak se tento dá rozšířit (aby práce s ním byla ještě efektivnější/příjemnější...) začne kydat oslavné ódy na <whatever> těžkotonážní a (mnohdy i nikdy nevyužitými) funkcemi nabité oblíbené IDE?
Copak tento článek srovnává vim a nějaké IDE?
PS: pokud někomu stačí nadpis, to je potom těžké ...
Velmi doporucuji tento plugin: http://www.vim.org/scripts/script.php?script_id=273
ctags je skvely nastroj, ale tukat porad prikazy zdrzuje :)
Na to odsazování s tabulátory vs. mezery doporučuji:
http://www.freehackers.org/Indent_Finder
Automaticky detekuje zda se v souboru používají mezery nebo tabelátory a podle toho nastaví proměnné.