Internet Info, s.r.o. Lupa Měšec Podnikatel Root Zdroják DigiZone Slunečnice Vitalia TopDrive KupDnes Navrcholu NovýTarif Dobrý web Weblogy Woko Jagg Computer.cz SK: MojeLinky

Hlavní navigace

Názory k článku
Textový editor Vim jako IDE (14.část: automatické formátování textů)

Tom
Tom (neregistrovaný) 213.29.199.---
29. 9. 2011 1:34 Nový

Šířka textu při wrap

celé vlákno

Hledám nastavení zalomení, aby wrap zalamoval po určitém počtu znaků, ne na okraji okna. Neví někdo, jestli takové existuje?

aaa158 aura:95
29. 9. 2011 9:45 Nový

Re: Šířka textu při wrap

celé vlákno

textwidth ?

Tom
Tom (neregistrovaný) 213.29.199.---
29. 9. 2011 23:42 Nový

Re: Šířka textu při wrap

celé vlákno

textwidth do textu vkládá zalomení řádku, což nechci. Chtěl bych jen nastavit zobrazení, ne měnit obsah.

Re: Šířka textu při wrap
Re: Šířka textu při wrap (neregistrovaný) 147.213.65.---
6. 10. 2011 14:16 Nový

Re: Šířka textu při wrap

celé vlákno

:set wrapmargin
:set wm

Čavo
Čavo (neregistrovaný) ---.87-197-115.telecom.sk
29. 9. 2011 13:50 Nový

13. časť

celé vlákno

13. časť, nešťastníčka, vypadla?

Alebo v rámci teórie nešťastných čísel bola vynechaná zámerne?

:-D

Pavel Tisnovsky
Pavel Tisnovsky (neregistrovaný) ---.redhat.com
29. 9. 2011 14:04 Nový

Re: 13. časť

celé vlákno

ha, vypadla omylem, resp. dil je to spravny (nic se neztratilo), jen to Ctrl+A jsem asi zmacknul dvakrat :-(

Diky za upozorneni!

Evidentne je pravy cas vsechny dily sloucit do jednoho serialu, to by se odchytlo hned na zacatku (puvodne se melo jednat o 2-3 clanky, se mi to nejak vymklo z rukou) ;-)

Čavo
Čavo (neregistrovaný) ---.87-197-115.telecom.sk
29. 9. 2011 14:45 Nový

Re: 13. časť

celé vlákno

Celkom by to potešilo, keby sa to podarilo zlúčiť.

Ďakujem za veľmi príjemný seriál. Síce používam ViM už hádam desaťročie, ale stále sa môžem dozvedieť niečo nové. Istý čas som si síce čítal ViM Help, ale keď to človek nepoužíva (stačí mu nejaká základná množina), tak sa mu to v tej šedej kôre, priveľmi nezohreje. A teraz sa po toľkých rokoch dozvedám, čo robím zbytočne nešikovne.

David Kovář aura:86
29. 9. 2011 15:38 Nový

Stav Caps Lock ve stavovém řádku

celé vlákno

Docela by mě zajímalo, jestli je možné nějakým způsobem dostat do stavového řádku informaci o tom, jestli je stisknutý Caps Lock nebo ne. Vzhledem k tomu, že víc koukám na obrazovku, než klávesnici dost často je právě Caps Lock zdrojem nepříjemných překvapení. Máte někdo radu? Dík

Pavel Tišnovský aura:98
29. 9. 2011 18:00 Nový

Re: Stav Caps Lock ve stavovém řádku

celé vlákno

Jde o to, jestli nekdy pouzivate Caps Lock skutecne k tomu puvodnimu ucelu. Ja se priznam, ze jsem ji nikdy takto nepouzil, jen me ta klavesa mate, proto si na ni mapuji Escape (dobre reseni, a to nejenom pro Vim). Popsano to bylo tusim ve druhe casti serialu.

Jinak pokud by se Caps Lock nepremapovalo, tak Vim nedostane informaci a stlaceni teto klavesy, Gvim vsak ano (jde odzkouset pres xev), tak by s tim snad slo neco delat.

David Kovář aura:86
29. 9. 2011 20:53 Nový

Re: Stav Caps Lock ve stavovém řádku

celé vlákno

Používám gvim. Já jsem celkem zvyklý Caps Lock používat (což asi neznamená, že bych si nemohl zvyknout jinak :-), takže to povětšinou není omylem, ale že jsem zapomněl "přepnout"

Kaminar
29. 9. 2011 16:53 Nový

Bez tabulátorů u :left, :right a :center

celé vlákno

Lze u příkazů :left, :right a :center používat formátování bez tabulátorů? O volbě expandtab vím, ale pokud je zapnutá, tak se expanduje na mezery i tabulátor po stisku klávesy Tab, a to nechci.

Pavel Tišnovský aura:98
29. 9. 2011 17:49 Nový

Re: Bez tabulátorů u :left, :right a :center

celé vlákno

Asi bude nejjednodussi si na to udelat vlastni prikaz, neco na zpusob:

:map :ll :set expandtab<cr>:lef­t<cr>:set noexpandtab<cr>

Trosku slozitejsi (s pomocnou promennou) to bude v pripade, kdy se ma zachovat nastaveni volby "expandtab"

Pavel Tišnovský aura:98
29. 9. 2011 17:51 Nový

Re: Bez tabulátorů u :left, :right a :center

celé vlákno

Hmm, jeste jsem v clanku mel zminit makro Justify, necham to na priste :-)

Kaminar
30. 9. 2011 9:34 Nový

Re: Bez tabulátorů u :left, :right a :center

celé vlákno

Děkuji za odpověď. Chtěl jsem zjistit, jestli neexistuje nějaká speciální volba Vimu, která by zachovávala funkci klávesy Tab (vloží vždy kód tabulátoru). Vypadá to, že asi ne. :)

Jen bych zmínil ještě jednu možnost, že kód tabulátoru lze vložit bez ohledu na nastavení volby "expandtab" pomocí kombinace: <Ctrl>-V <Tab>. V případě, že těch tabulátorů není mnoho, tak je to asi nejpohodlnější postup, o kterém vím. :)

Pavel Tišnovský aura:98
3. 10. 2011 13:54 Nový

Re: Bez tabulátorů u :left, :right a :center

celé vlákno

Hmm prave tady by mohlo pomoci mapovani:

:iunmap <C-V>

:imap <Tab> <C-V><Tab>

Resp. si jeste udelat nejaky prepinac mezi <Tab> a mezerami, tj. zapinat a vypinat toto mapovani

dumblob
dumblob (neregistrovaný) 2001:67c:1220:----:----:----:----:----
30. 9. 2011 18:56 Nový

"vyssi divci"

celé vlákno

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 :).

dumblob
dumblob (neregistrovaný) 2001:67c:1220:----:----:----:----:----
30. 9. 2011 19:04 Nový

Re: "vyssi divci"

celé vlákno

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

dumblob
dumblob (neregistrovaný) 2001:67c:1220:----:----:----:----:----
30. 9. 2011 21:41 Nový

oprava

celé vlákno
...
" Esc vzdy vyskoci z tohoto menu, ale neprepne do normal mode
" (tzn. zustaneme v insert mode);
...
Pavel Tišnovský aura:98
3. 10. 2011 13:58 Nový

Re: "vyssi divci"

celé vlákno

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

Pavel Tišnovský aura:98
3. 10. 2011 14:00 Nový

Re: "vyssi divci"

celé vlákno

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 :-)

dumblob
dumblob (neregistrovaný) 2001:67c:1220:----:----:----:----:----
5. 10. 2011 20:07 Nový

Re: "vyssi divci"

celé vlákno

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 :)

Pavel Tišnovský aura:98
6. 10. 2011 16:10 Nový

Re: "vyssi divci"

celé vlákno

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)

dumblob
dumblob (neregistrovaný) 2001:67c:1220:----:----:----:----:----
9. 10. 2011 21:40 Nový

Re: "vyssi divci"

celé vlákno

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).

dumblob
dumblob (neregistrovaný) 2001:67c:1220:----:----:----:----:----
13. 10. 2011 17:40 Nový

Re: "vyssi divci"

celé vlákno

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.

Zasílat nově přidané příspěvky e-mailem