Názory k článku Vim sedm - první část
-
Frantisek Rysanek (neregistrovaný)Spellchecker pri psani programu nepostradam.
Na druhou stranu pomerne dlouhou dobu na wishlistu vede context-sensitive code autocompletion. To jsem zvedav, jestli se to alespon naznakem dostane do ostre verze VIM 7. Rozumim tomu, ze jde o pomerne slozitou vlastnost, ktera vyzaduje mj. urcity stupen porozumeni syntaxi editovaneho jazyka, takze neni univerzalni pro ruzne jazyky, taky to znamena indexaci odkazovanych "hlavickovych souboru" apod. -
Pavel TišnovskýZlatý podporovatelOno je to s autocompletion ještě o moc horší. V C-čku a C++ by se ještě dal napsat Vim skript, který všechny hlavičky projde a bude funkce/metody na požádání dopisovat. Ale například v Javě se s tímto dostanete do velkých problémů, protože metody objektů ze standardních knihoven (a knihoven třetích stran) jsou uloženy v binárním formátu a parsování je poměrně pomalé a náročné na paměť, jak je ostatně patrné z Javovských vývojových prostředí.
Některé skripty, které se o autocompletion pokouší, jsou na http://www.vim.org, zkoušel jsem je, ale moc mě svojí rychlostí a funkcionalitou neuspokojily. V každém případě je podle http://www.vim.org/sponsor/vote_results.php autocompletion na prvním místě v požadavcích na nové funkce Vimu. -
Pavel TišnovskýZlatý podporovatelMáte pravdu v tom, že struktura například Javovských .class souborů je poměrně jednoduchá a parser by mohl být i rychlejší, než v případě zdrojových souborů například C++ (a to nepočítám vychytávky typu preprocessor, které však nezvládají ani mnohé IDEčka).
Problém je například v tom, jak účelně a rychle naparsovat takový java.io.FileOutputStream (například). V JRE 1.4.2 se musí přečíst určitá část z komprimovaného souboru rt.jar, který má v této verzi něco přes 20MB. Je jasné, že díky struktuře tohoto souboru (=zip) se nemusí provést rozpakování všeho, ale i tak to bude trošku seekovat, rozbalovat, parsovat atd. No a pro každý zdrojový řádek s "importem" se musí pořád dokola dělat ta samá činnost, takže pro Vim to určitě jednoduché není. -
Culibrk (neregistrovaný)Mozna by slo "predparsovat" javove knihovny do "jednoduzsiho" formatu, ten drzet v pameti, po startu nahravat, preparsovat pouze v pripade, ze se original zmeni a pak ulozit na disk. Jooo, kdyz ma jedna systemova knihovna 20M, pak bude mit rozbalena nejakych (rekneme) 100, takovych knihoven je tam mraky, tak at si Java fanousci priplati za RAM... S tou Javou je vic problemu, nez uzitku... ;-) (No flame pliizz..) Anebo si jen v pameti drzet index kde co je a knihovnu rozbalovat az pri pozadavku doplneni. Uzivateli je uz jedno, jestli ceka 500ms nebo 600, ale 100xnic umorilo osla.
-
abyssal (neregistrovaný)Ono by to slo predgenerovat. Pomocou Java reflexie by nebol problem prejst classpath a z kazdej classy/pakazu vyextrahovat "header file", ktory by obsahoval fieldy, metody, konstruktory, podtriedy, podbaliky. Z toho by vypadol jeden textak, alebo viac (podla toho, ci vsetko natlacime do jedneho suboru alebo bude osobitny pre kazdu classu/pakaz). To by si uz s tym ten skriptovaci jazyk nejak poradil. Prechrumanie vsetkych classov by chvilku trvalo, ale staci to spravit len raz pre standardne triedy. Pre ostatne by sa musel robit priebezne (po kazdom save jak to robi napr. eclipse).
Druha moznost je vytvorit java command-line utilitu, ktora dostane na vstup co chceme doplnit, napr. 'java.lang.BigInteger.toS' a vrati mozne doplnenia (toString) na vystupe. Rozparsuje podla pakazov, prejde classpath a v poslednej urovni (za poslednou bodkou) hlada podla kontextu bud balik/class/metodu. Neviem, jak moc by to oplyvalo rychlostou, asi ten prvy pristup je lepsi.
Skor by ma zaujimalo, ako spravit nejak efektivne zistenie celeho kvalifikovaneho nazvu triedy (tj. aj s pakazmi):
import javax. ... .*;
import javax. ... .*; //vela dalsich importov
import cz.volaco.mojbalik.*; //v tom baliku mam triedu FileAbstraction
FileAbstraction fa;
//tuto pisem
fa.get //teraz zavolam ten autocompletion, tak musi zistit, akeho je fa typu, zistit importy... -
Pavel TišnovskýZlatý podporovatelTady je to spíš myšleno tak, že po zadání řetězce "fa." (tedy hned po té tečce) by se mělo zobrazit kontextové menu s vhodnými názvy metod a datových položek. Při zadánávání dalších písmen nebo posunem kurzoru po menu by se provedlo doplnění. Ideálně by se ještě měly v tom kontextovém menu doplnit informace o vybrané metodě - argumenty, funkce, návratové hodnoty atd.
Klasické VIMovské autocompletion přes Ctrl+N, Ctrl+P a Ctrl+X by sice po úpravách taky šlo použít, ale chybí mi tam ty další informace pěkně seřazené v kontextovém menu. Jedině by to muselo být uděláno tak, že by se (například při ukládání souboru) vytvořil slovník se všemi možnými kombinacemi, například: fa.print(), out.print(), Math.abs() apod. Při doplňování by se pouze nastavilo, že tečka je běžný znak. Mimochodem, ze slovníku se dá doplňovat pomocí Ctrl+X Ctrl+K. -
earl365 (neregistrovaný)Autocompletion v jave je v principe jednoduchsi ako v C++. Class subory maju dost jednoduchu strukturu (a hlavne pevne urcenu), kym parsovanie zdrojaku v C++ je pomerne narocny proces, zvlast pri pouziti preprocessora (bez ktoreho sa to v podstate ani neda, kedze skoro vsetky vacsie kniznice pouzivaju v hlavickovych suboroch nejake direktivy preprocesora).
Pochopitelne parsovanie standartnych java kniznic sa robi iba raz (a trva to dost dlho), potom sa to ulozi do cache. Parsuju sa stale cele JAR subory naraz, takze overhead kvoli kompresii je minimalny. Vyhladanie v ulozenom repozitare je podla mojich skusenosti dost rychle. Trochu vacsi problem je vyhladavanie v dokumentacii. Toto som nevidel este v ziadnom C++ autocomplete (asi pre to, ze pre c++ nie je standardizovany format API dokumentacie (ja viem, doxygen :)), kym v jave je javadoc. Netbeans vyhladava priamo v javadoc suboroch (html), co trochu trva, kym eclipse pouziva zdrojove kody, co sa (aspon mne) zda rychlejsie. Asi kvoli kvalitne zoptimalizovanym parserom java kodu. -
Pavel TišnovskýZlatý podporovatelS tou složitostí parsování C++ zdrojáků máte naprostou pravdu. Dokonce si dovedu představit situaci (tedy nemusím si ji představovat, reálně ji nejenom já používám), že se podle parametrů zadávaných překladači překládají úplně jiné části kódu (pomocí #ifdef atd). S tímto si už z principu nemůže parser jednoznačně poradit.
Ta neexistence kontextové nápovědy v C++ je určitě také kvůli neexistujícímu standardu pro tvorbu dokumentace ve zdrojácích. U Javy je to jasné již z normy, C++ toto v normě nemá a i kdyby měl, tak by se to nedalo použít na -
Pavel TišnovskýZlatý podporovatelZe začátku to určitě stačí, jen potom člověk nesmí dělat v žádném IDEčku, které doplňování obsahuje (po tečce, šipce atd.) většinou pomocí kontextového menu :-). K tomu se většinou ještě přihodí krátký komentář ke každé metodě/datové složce a typy vstupních a výstupních parametrů. Je to poměrně návyková věc...
-
Pavel TišnovskýZlatý podporovatelZkuste si stáhnout a přeložit beta verzi, už je reálně použitelná. Kromě samotného vytváření slovníku (to je nestabilní) vše zatím funguje - sám sedmou verzi na jednom počítači provozuji jako primární editor.
-
Pavel TišnovskýZlatý podporovatelJa jsem to na XPckach prelozil jednoduse pomoci GCC, ktery je dostupny z baliku MinGW. Klidne Vam muzu na soukromy e-mail poslat i prelozene .exe s ceskym slovnikem.
Pouzil jsem docela stary prekladac:
C:\>gcc --version
GCC.EXE (GCC) 3.2 (mingw special 20020817-1)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Teoreticky by sel preklad provest i pomoci jinych prekladacu. Muzu to vyzkouset na Borlandim BCC, dalsi (VC, Watcom) ted nemam k dispozici. -
maros (neregistrovaný)Odporucam navstivit stranku http://users.skynet.be/antoine.mechelynck/vim/ kde sa velmi rychlo po vydani novych patchov objavuju binarky pre stabilnu verziu 6.3 aj pre alpha verziu 7.0.
-
Pavel TišnovskýZlatý podporovatelS původními skripty pro Vim 6 by neměl být problém, interní slovník ve Vimu je však mnohem lepší - prostě jsou všechny překlepy ihned na první pohled viditelné, bez nutnosti postupně (sériově) procházet celým textem.
-
Ja tomu tedy prave take moc nerozumim, protoze me vimspell checkuje inkrementalne on the fly - kdyz pisu, prubezne to slova kontroluje ispellem/aspellem a highlightuje mi to neznama slova (cervenym pozadim - GUI nepouzivam). V cem je integrovany spellchecker lepsi, krom toho, ze bude mozna o malinko rychlejsi? -
Pavel TišnovskýZlatý podporovatelAha, takhle já jsem ispell nastavený neměl - kontrola se prováděla až na požádání, dejme tamu na klávesovou zkratku, nebo při opuštění vkládacího režimu. Pokud máte externí speller (tj. ispell/aspell atd.) nastavený tak, že se při _jakékoli_ změně textu na tu změněnou část zavolá, opravdu asi nebude - tedy kromě rychlosti - mezi interním a externím spellerem rozdíl.
-
JM (neregistrovaný)Podle výsledku hlasovaní je spellcheck až 23 požadovaná funkce. Předtím je ještě už zmíněné context-sensitive doplňování.
Mě dost mrzí, že se z VIMu dělá taková bublina. Radši bych dal přednost větší integraci s nějakým jiným jazykem (Python), ať je to použitelnější.
Další pěkná featurka by byl refactoring. IDE to už mají celkem běžně, ale já bych chtěl refactorovat třeba LaTeXovský zdroják (makra). -
Pavel TišnovskýZlatý podporovatelNo, teď už je na jednadvacátém místě :-) Ale to je vcelku irelevantní. Všichni totiž ví, že ve Vimu spellchecker je/bude, tak proč by pro něj měl ještě někdo hlasovat?
S tou integrací na další jazyky je to docela dobré, vždyť Pythonovské skripty spolu s Vimem komunikují už od šesté verze. Skriptovací jazyk Vimu se v sedmičce hodně rozšířil, počkejte si na další díl. Zatím se sice nejedná o OOP jazyk, ale on také není určen pro psaní nějakých větších projektů.
Refactoring mi také ve Vimu chybí, ale tady si myslím, že to není problém přímo distribuce Vimu, ale vhodných skriptů od dalších autorů. Refactoring totiž není (narozdíl od realtimového spellcheckeru) až tak pomalá záležitost, že by se musela programovat přímo do binárky. -
Pavel TišnovskýZlatý podporovatelMrknete se na http://en.wikipedia.org/wiki/Refactoring nebo do nejake knizky o XP (ne Windows :-)
-
Tedy refactoring LaTeXovskeho zdrojaku (maker), jak psal puvodni autor, znamena neco jako :%s/\\m\>/\\makro/g ? ;-) To zas neni takovy problem napsat, i kdyz by se mi mozna docela libil shortcut podobny #/*, ktery by vsak pouze predvyplnil :%s/\<keyword\>//g a hodil mi kurzor na posledni lomitko. To me dle toho clanku ve Wiki napada jako jedina mozna "podora refactoringu". Takze v tom asi bude neco vic...? ;-)
-
benzin (neregistrovaný)Refaktorovani je upravování zdorojového kódu takovým způsobem, aby se nezměnila jeho funkčnost, ale aby se zlepšila jeho čitelnost a zjednodušila jeho údržba.
Takže to v sobe zahrnuje strašnou spoustu úkonů, nekteré jsou automatizované, některé ne. Některé jsou všeobecně známé, některé používá třeba jenom jeden člověk na světě.
Jsou v tom zahnuté jednoduché přejmenování proměných, metod a tříd, přes vykopírovávání metod ze tříd atp. Je toho spousta co refaktorovací nástor podporuje. -
Ash (neregistrovaný)cd /usr/share/vim/vimfiles/spell
wget http://ftp.vim.org/vim/runtime/spell/README_cs.txt \ http://ftp.vim.org/vim/runtime/spell/cs.utf-8.spl \
http://ftp.vim.org/vim/runtime/spell/cs.iso-8859-2.spl \
http://ftp.vim.org/vim/runtime/spell/cs.cp1250.spl
Oba slovníky naráz:
:set spelllang=en,cs
:set spell
