Hlavní navigace

Vlákno názorů k článku Textový editor Vim jako IDE (14.část: automatické formátování textů) od dumblob - Dekuji za pekny serial, ktery mne ruznym novym...

  • Článek je starý, nové názory již nelze přidávat.
  • 30. 9. 2011 18:56

    dumblob (neregistrovaný) 2001:67c:1220:----:----:----:----:----

    Dekuji za pekny serial, ktery mne ruznym novym vecem naucil. Nektere vsak porad nevim jak resit, a proto bych rad pozadal o radu.

    1) Pri editaci/pohybu_v souboru obsahujicim napr. php kod s nekolika ikonkami ulozenymi v base64 se Vim casto uplne zasekne (C2D 2,5Ghz; 4GB RAM) po treba i desitky vterin. Pri hledani chyby jsem zjistil, ze za vsechno muze zvyraznovani syntaxe. Toho se vsak nechci vzdat. Napadlo mne, jestli by nesla nastavit nejaka konstanta, ktera by urcovala maximalni delku retezce, ktery bude regularnim vyrazem zpracovavany (protoze syntaxe je resena regularnimy vyrazy). Ale nic takoveho jsem nikde nenasel.

    2) Rad bych mel v konfiguraku spolehlivy a zejmena multiplatformni (Mac/Win/POSIX) zpusob, jak zjistit kolik barev muze Vim pouzivat. Nyni pouzivam nevyhovujici:

    if $TERM =~ '^xterm'
            set t_Co=256
    elseif $TERM =~ '^screen-bce'
            set t_Co=256  " screen - just guessing
    elseif $TERM =~ 'screen'
            set t_Co=256  " tmux - just guessing
    elseif $TERM =~ '^rxvt'
            set t_Co=88
    elseif $TERM =~ '^linux'
            set t_Co=8
    else
            set t_Co=16
    endif

    V POSIX systemech mam nejradsi editaci v konzoli (terminal, nebo nejaky emulator - nejcasteji xterm). Zajimalo by me tedy jak detekovat moznosti emulatoru terminalu nebo samotneho terminalu (termcap? terminfo? dircolors? tput colors? infocmp?). Zatim mam v .bash_profile takovou malou heuristiku pouzivajici pouze `dircolors', ale to ceka na napravu :).

    3) Jak resit detekci typu souboru podle mime-type? Napadlo me pochopitelne reseni pomoci externiho volani file - ale to bych si musel vytvorit obrovskou tabulku podporovanych typu souboru vimu (to budou stovky, protoze minimalne nekolik set je ruznych typu zvyraznovani syntaxe), coz povazuji za krajne nevhodne reseni. Edituji casto ruznorode soubory, takze abych si udelal tabulku o 20 polozkach neprichazi v uvahu - nestaci to a i tak je to velice neelegantni.

    4) Takovy postesk :). Nezahledli jste nekde nejaky patch, ktery by umel umistit statusline a ruler nahoru na prvni radek (a ne na ten posledni)? Pravdepodobne by mi to vyhovovalo vice - nevim, musel bych vyzkouset. Ale kazdopadne se mi nepodarilo nikde nic najit.

    Mel bych par dalsich, ale ty tolik nehori. Napr. doplnovani tabulatorem takove, abych nemusel sundavat ruce z klavesnice - tzn. zadne sipky a abych nemusel pokud mozno mackat zadne Ctrl ani Alt.
    Moje predstava jak tohle resit je nasledujici:

    " Shift+Tab otevre completion menu; psanim vyhledavam nejblizsi match
    " v tomto menu se mohu pohybovat pomoci Tabulatoru dolu
    " a pomoci Shift+Tab nahoru
    " Enter potvrdi vyber
    " Esc vzdy vyskoci z tohoto menu, ale neprepne do visual mode
    " po stisknuti `u' (vraceni v historii) to smaze vsechno doplnene (tzn. NE to,
    " co jsem natukal rucne na klavesnici - samozrejme na to ma vliv interni casovy
    " interval, kdy je neco povazovano jeste za slovo a kdy za sekvenci oddelenych
    " znaku)

    Nebo napr. Ctrl+F a Ctrl+B nebudou hybat s pozici kurzoru, nybrz pouze s textem (takze kdyz dvakrat zmacknu Ctrl+F a hned pote dvakrat Ctrl+B, tak kurzor bude na totoznem miste jako byl pred prvnim zmacknutim Ctrl+F).
    Take aby napsani dts<jakykoliv white znak - takze i LF nebo CR atd.> vlozilo aktualni timestamp. Nyni to mam nasledovne:

    iabbr <expr> dts strftime("%Y-%m-%d %H:%M:%S %Z")

    Ale to funguje pouze kdyz napisu dts<mezera>.
    Krome toho by bylo hezke, aby vim v emulatoru terminalu menit titulek podle aktualne editovaneho bufferu - nyni si v xtermu zobrazuji posledni spusteny prikaz v shellu.

    Tak tedka uz by to mohlo byt opravdu vse, co jsem mel na srdci :).

  • 30. 9. 2011 19:04

    dumblob (neregistrovaný) 2001:67c:1220:----:----:----:----:----

    kontakt "d u m b l o b" bez mezer na gmail.com

  • 30. 9. 2011 21:41

    dumblob (neregistrovaný) 2001:67c:1220:----:----:----:----:----
    ...
    " Esc vzdy vyskoci z tohoto menu, ale neprepne do normal mode
    " (tzn. zustaneme v insert mode);
    ...
  • 3. 10. 2011 13:58

    Pavel Tišnovský

    Zdravim. Zkusim napred odpovedet na prvni otazku. Existuje volba

    :syntax sync ....

    kde lze za .... dosadit jednu z podporovanych metod synchronizace pri "obarvovani" kodu. Vim totiz v nekterych pripadech zacina skenovat dokument od zacatku, aby napriklad zjistil zacatky komentaru, nebo v pripade cecka preprocesorove prikazy typu #if 0/#endif (coz v podstate vede k zakomentovani casti kodu)

    Zvlaste vykon ovlivnuji volby minlines a maxlines, popripade fromstart (ta je samozrejme nejpresnejsi, ale nejvice narocna).

    Viz tez :help :syn-sync

  • 3. 10. 2011 14:00

    Pavel Tišnovský

    Jeste dodam, ze mam nekdy problem se slozitejsimi HTML dokumenty, pokud je Vim spusteny v terminalu. Pri prekresleni obrazovky se totiz musi pri zmene barvy (coz muze byt klidne kazde 3-4 znaky) vysilat pomerne slozite prikazy pro rizeni terminalu (escape sekvence) a terminal je potom musi interpretovat, coz muze byt slozite. Gvim timto problemem az tak netrpi, coz je mozna trosku paradoxni, protoze je tady zazita predstava, ze programy s GUI jsou vzdy pomalejsi :-)

  • 5. 10. 2011 20:07

    dumblob (neregistrovaný) 2001:67c:1220:----:----:----:----:----

    Dekuji za odpoved na prvni dotaz. Vase navrhy co nevide dukladne vyzkousim.
    Mimochodem opravdu rad edituji v terminalu, takze urcite vyzkousim GUI variantu. Jinak me ani nenapadlo, ze by GUI mohlo byt pomalejsi :)

  • 6. 10. 2011 16:10

    Pavel Tišnovský

    Jeste mala poznamka k tem barvam. Zpusob detekce poctu barev vam bohuzel neprozradim, ale (u)rxvt je mozne opatchovat na pouziti vsech 256 barev, takze byste mel case o jednu polozku mensi :-)

    Ten patch je schovany ve zdrojovem balicku rxvt v adresari doc/ (to je dobra schovka)

  • 9. 10. 2011 21:40

    dumblob (neregistrovaný) 2001:67c:1220:----:----:----:----:----

    To je tedy opravdu dobra schovka. Jesteze jsou v repozitari dostupne predkompilovane verze s timto patchem jiz aplikovanym.

    Kazdopadne jsem vyzkousel GUI a sice je o chlup rychlejsi, ale cca tak o 10%, maximalne 20%. Coz je imho porad velky zasek (napr. 4 cele vteriny v testovacim php souboru - mohu ho poskytnout). Otestoval jsem pritom vsechny 4 metody synchronizace vcetne (max|min)lines (ty jsem zkousel nastavovat na 1; 2 nebo 3).

    Jinak ty zaseky jsou mnohem kratsi kdyz pouzivam "page down/up" scrollovani a ne scrollovani po 1 radku.

    Presto dekuji za napady. Na webu jsem diky tomu nasel jiz relevantni clanky lidi s podobnymi problemy - napr. LaTeX syntaxe pry ma podobne chovani. Bohuzel nikde neni zadne "hotove" reseni. Vzdy pouze castecne (napr. nastaveni foldmethod na manual, coz rychlost cca o 20% zvysi).

  • 13. 10. 2011 17:40

    dumblob (neregistrovaný) 2001:67c:1220:----:----:----:----:----

    Tak podle "oficialnich" informaci od vyvojaru a znalcu Vimu je to bohuzel vlastnost a tim padem "neresitelny" problem. Nejlepsiho vysledku lze dosahnout pomoci
    set nocursorline
    A trochu take pomoci
    set synmaxcol=200
    Cislo 200 je jiz tak nizke, ze zlepsuje odezvu a pritom je jeste snesitelne co se funkcionality tyce.

    S tim, co vznikne se vsak jiz clovek musi smirit. Posledni veci by bylo nejak zautomatizovat automaticke zapinani techto voleb prave pouze pro problemove soubory, coz je pro me tvrdy orisek (preci nebudu skenovat cely soubor, abych se o nem dozvedel dulezite informace). Zase na druhou stranu jsou takoveto soubory v mem pripade takovou raritou, ze tyto volby zapinam rucne.

    Jeste jednou dekuji za nakopnuti. Ostatni pozadavky/problemy uvedene v puvodnim postu zase necham nejaky cas ulezet a snad se k nim brzy vratim.