Vlákno názorů k článku Historie vývoje textových editorů: programátorské textové editory pro DOS od A.S. Pergill - Asi nejlepší editor pro DOS vůbec. Řadu jeho...

Čili je to podstatně méně výhodné než makra v csed, kde jsem mohl mít např. všechny html znaky jako jednu sadu maker, všechny příkazy v javě jako další sadu maker (atd.) a když jsem nahrál do editoru příslušný soubor maker, tak to vše bylo na dvouklávesových kombinacích. A každá ta sada maker byla extra soubor, který se dal překopírovat na disketu a přenést na jiný počítač.

Jenže právě není nikde popsáno, jak uložit třeba ta makra k html a jak je zase zpětně načíst. Vazba na typ souboru je spíše zmatečná věc.

Já v téhle obskurnosti opravdu žádné výhody nevidím. Jsem toho názoru, že typy volaných funkcí (makra, skripty atd.) by měly být přehledně oddělené.

Jako makro si představuji sled příkazů dostupných z klávesnice. Např. se přesunout na začátek následujícího řádku a něco tam vložit. V extrémně minimalistickém případě vložení znaku, který není na klávesnici (takto jsem měl v "psacím" makru místo < a > "namapovány" francouzské uvozovky, které vyžadoval ve zdrojáku sázecí program mého tehdejšího nakladatele, konkrétně tohle dnes řeší TeX lépe).
Pro složitější věci spíš vložím do textu nějakou značku a pak ho přežvýkám uložený na disku perlovským skriptem. Z tohoto důvodu opravdu nepotřebuji pro běžné psaní nějaká supersložitá nebo "inteligentní" makra, nebo samostatný makrojazyk.

Začínám chápat, takže klasický trolling:
1) "Vim to neumí"
2) když další řeknou, že umí, tak "je to moc složitý, není dokumentace"
3) když další řeknou, že není složitý a je dokumentovaný "ale já vlastně do dokumentu vkládám obskurnosti a používám Perl pro expanzi" (tím pádem zahazuješ jakoukoli rozumnou formu spolupráce na dokumentu)

Dobrý triky, takže to bude skutečně nejlepší zůstat u primitivního editoru a k tomu se učit jeden z nejbizarnějších jazyků vůbec (Perl :-)

Takže ještě jednou:

1) to, co se ve Vimu zaznamenává přes @ a vyvolává přes q jsou většinou throwaway makra, která se sice automaticky ukládají do .viminfo, ale můžeš takto použít asi jen 30 expanzí a ještě se to blbě vyvolává

2) pro expanzi přímo při psaní je dost dobré použít :iabbrev, zkráceno na :iab Klasická expance, nějaké ty závorky, náhrada ,bb za , tex za \TeX atd. atd.

3) na všechno ostatní se používá příkaz :map a jeho varianty. Díky tomu máš k dispozici *všechny* možné klávesové kombinace, jak zkratku vyvolat

Dobře, budu konkrétní. V csedu jsem si mohl např. pro psaní v TeXu napsat makro, které na stisk jedné dvoukombinace kláves umělo napsat třeba
\begin{tabular}{}\hli­ne
\end{tabular}
a přesunulo kursor do těch složených závorek, kam se píšou parametry tabulky.
Když jsem pracoval na zdrojovém textu pro TeXový dokument, tak jsem nahrál příslušnou sadu maker pro psaní TeXu a mohl jsem je použít. Při psaní textů jiného typu (třeba program v javě) jsem nahrál jinou sadu maker a příslušná kombinace kláves, pokud byla využita, dělala něco úplně jiného. Takže se mi nemohlo stát, aby se mi třeba javovské příkazy pletly do TeXu a naopak, jak se může stát, pokud to mám neoddělené (jak je to zřejmě v tom vim).
1. Čili něco, co zhruba odpovídá těm vašim makrům ukládaným přes @ a volaným přes q, byla makra v csedu, ale dala se volat daleko jednodušeji a intuitivněji a s menším rizikem náhodného spuštění při přehmátnutí se na klávesnici, takže i ergonomičtěji.
2. Klasickou expanzi (kdy editor "cosi" automaticky doplňuje do textu) odmítám používat, v editorech, kde to je a jde to vypnout, tuhle funkci vypínám a editory, kde to nejde vypnout, pokud možno nepoužívám. Tudíž její existence ve vim pro mě žádnou výhodu nepředstavuje (maximálně zvýšení rizika, že to náhodně spustím a rozdrbu si dokument).
3. Volání příkazu :map a něco k tomu je neskutečně složitější a ergonomicky nevýhodnější než současné zmáčknutí dvou kláves (jako v bodě 1).

takže to není troll, je to blbec :-)

Takže znovu:
1. Mám zájem makra, která se budou spouštět na současný stisk dvou kláves.
Protože kláves je omezený počet (i s kombinacemi <Ctrl> a <Alt> a <Shift>), vyhovovalo mi naprosté oddělení různých skupin takto nadefinovaných maker (do různých souborů z nichž jeden se explicitně nahrál do editoru a další jakoby neexistovaly).
Asi jak funguje jediné makro pro vim, které používám, které po stisku <F8> umožní volbu kódování.
2. Nemám zájem o
- to, aby přístupnost nebo postup vyvolání maker závisely na typu souboru
- něco, co mi pod rukama mění nebo "intuitivně dopisuje" psaný text (jak to dělá "expanze" třeba u různých kancelářských editorů)
- současný přístup ke všem možným (existujícím) makrům, protože to zbytečně
-- komplikuje dostávání se k tomu, co potřebuji
-- zvyšuje riziko překlepů a dalších chyb
- něco, co budu spouštět z příkazového režimu, tj.
-- musím přepnout do něj,
-- musím zadat dvojtečku a příkaz map
-- musím zadat název nějakého příkazu
- možnost nějakého složitého skriptování, protože to raději budu řešit jinými prostředky než editorem

Prostě, jak to bylo uděláno v csedu, tak mi to vyhovovalo podstatně víc a bylo to i ergonomičtější, než jak je to uděláno ve vim (které sebou ve své koncepci vláčí dědictví velmi primitivních poměrů a omezených možností před érou DOS).

Příkazy vim znám a některé používám. Nicméně, nezlobte se vy, ergonomicky je docela rozdíl spouštění nějakého příkazu na víc ťuknutí do klávesnice a zmáčknutím dvou kláves současně. A to ve prospěch té druhé možnosti.
Jinak csed nemohu používat, protože se mi pod DOSBoxem nepodařilo vyřešit českou klávesnici. Pokud bych to rozchodil v DOSBoxu, tak bych se, pochopitelně, nemusel zalamovat s monitorem. Absence UNICODE (nebo UTF8) je to nejmenší, co by mě trápilo, stejně, když něco píšu pro zpracování TeXem, tak se to musí psát v ISO-8859-2, případně do tohoto kódování konvertovat (vim je jeden z mála editorů na linuxu, které toto kódování umějí, myšleno bez nějakých problémů). Ta "univerzální" kódování jsou jen zdroj nekompatibilit (pokud někdo má názvy souborů s diakritikou nebo jinými exotickými znaky, tak s nimi řada programů neumí korektně pracovat) a dalších problémů. Jsou prostě jako "superuniverzální nůžky", které měl pan Souček ve své knize "blázniví vynálezci", které měly snad třicet funkcí, ale stříhat se s nimi dalo mizerně. Jejich vynucené používání (někdy po roce 2000) jsem nesl těžko, do té doby (Mandrake a první Mandriva po jeho zániku) jsem si je nastavoval vždy jako druhotná, pro použití jen v jasně definovaných případech (např. titulky k filmům).
Nehodlám vám brát vim, sám jsem nucen ho na některé věci používat, a proto také pociťuji, že v oblasti maker při praktickém používání za csed těžce zaostává, jak z hlediska funkčnosti (počet maker na klávesnici), tak i z hlediska ergonomie. Vyzkoušel jsem obojí, takže prostě vím, co mi vyhovuje lépe. Mít všechna makra v jednom souboru, který má navíc "natvrdo" nastavený název, považuji za víc nevýhodu než výhodu

1) s Ctrl, Alt apod. jde ergonomie dolů, píšete vůbec na klávesnici správně nebo stylem pana Semtamťuka?

2) I kdyby CSED nakrásně jel v DOSBoxu, pořád to bude umět jen nějaká prastará rozlišení, takže "dobré" pro očička

3) Unicode - to je vtip co píšete žejo? Nebo jste někde na konci řetězce tvorby dokumentace a ten text jde jen na vytištění? S nikým dalším se nespolupracuje, žadný e-bookový výstup, nic? Zajímavé, asi fakultní prostředí...

4) s těmi makry to není pravda, mohou být klidně v deseti souborech, proč to pořád opakujete???

1. Pokud je alternativou přepnutí do příkazového modu a volání příkazů, tak asi ne. Školený na klávesnici nejsem, ale úhozů mám vcelku dost.
2. Rozlišení programů v DOSBoxu řeší OS, tam problémy nejsou. Stejně většinou píšu, nebo jinak pracuji, v emulátoru konzoly.
3. Opravdu nemám potřebu psát mnohojazyčné texty s mnoha autory různých národností (kde má použití Unicode či UTF-8 asi opravdu velký přínos). Opakovaně jsem se setkal s tím, že zazipované adresáře nešly rozzipovat, protože jména souborů byla v Unicode nebo UTF-8, případně s dalšími podobnými problémy.
e-book bych rozhodně přes Unicode neřešil, od toho je pdf, a to mohu udělat v TeXu. Formáty typu epub nebo pdb jsou jen na zlost. Stahoval jsem si Gliese (časopis o exoplanetách), co to přestali dělat v pdf a přešli epub, tak jsem s tím přestal, protože tahle konkrétní verze formátu epub, co používají, je win/apple only, na linuxu to nic korektně nezobrazí (prostě obskurní formáty s obskurním kódováním češtiny, u nichž není zaručeno korektní zobrazení a nezobrazují se korektně ani obrázky, a to na vícero verzích Debianu s FBreaderem, kdy je výsledek prakticky stejný, jeden z těchto formátů má umět načíst Libreoffice, ale nesetkal jsem se se souborem, u něhož by se to povedlo). Tahle kódování jsou pro mě zcela bezcenná a jen přinášející problémy.
4. Protože to nikdo pořádně nevysvětlil, popsané to v dokumentaci rozumně není. Nehledě k tomu, že, jak jsem to pochopil ze zdejší diskuse, v jedné sadě maker na jednu klávesu může být ve vim podstatně méně příkazů než v tom csed (počet písmen angl. abecedy u vim versus několik set u csed).

Zrovna teď řeším opravy nějakého textu v libreoffice. Kurzor musí být 2 - 5 znaků napravo od míste, kde se v textu mažou nebo dopisují písmena (tedy jsem nucen to dělat zkusmo a na slepo) - protože UTF8, v němž se nedá korektně vztáhnout pozice písmene k nějakému byte v textu. Prostě nesmysl, který je jen zdrojem chyb a problémů.

A co zkusit věnovat se něčemu úplně jinému? Třeba okopávání brambor a tak... Z této diskuse mám pocit, že problém je mezi židlí a klávesnicí.

S linuxem pracuji cca 20 let. Takže se cítím být kompetentní k hodnocení, že to či ono se za tu dobu zlepšilo a jiné věci se zase zhoršily (a co fungovalo dřív, tak nefunguje, nebo funguje hůř).
Kdyby nebylo nuceného přechodu linuxového systému na UTF8, tak bych si vystačil s joe (který mi vyhovoval víc než vim, ale nenašel jsem, jak ho donutit ukládat texty kódované jinak, než co je natvrdo nastaveno v OS - na rozdíl od vim). A tahle diskuse by byla z větší části zbytečná.

Tech 20 let ocividne nestacilo, LC_ALL a kamaradi pomuzou? Ja pracuju v Linuxu sice jen 19 let, ale zato me utf8 nikde neskodi a velkou cast programu pouzivam, aniz by do nich utf8 vstupovalo. Nektery jiny naopak pouzivam s utf8, prece se to navzajem nevylucuje.

Tedy moc nechapu, proc by se v Libreoffice mel nekdo (jak?) divat na hodnoty jednotlivych bajtu. To je co za vychytavku? Vidim to spis na problem s praci s daty (nejsou zalohy ze? :-)

Ale i tak - v UTF-8 se *presne* vi, kde znak zacina, staci se podivat i jen na clanek na wikipedii, neni potreba se divat do normy.

Prostě jsem napsal text (jako zdroják pro TeX) v geditu, a protože výsledek měl být vedle tisku v presentační kvalitě odevzdán v odt nebo doc, tak jsem ho překopíroval a potřeboval jsem jen vymazat TeXové tagy, kterých tam naštěstí nebylo moc. A Libreoffice si zjevně nerozuměla s textem v iso-8859-2, písmenka sice zvládla správně, ale kursor neuměla najít.
Mimochodem, v textu kódovaném v utf8 musí program při skoku o 1000 písmen dopředu nebo dozadu projít všechny byte, protože jedno písmeno může být kódováno jedním až 3 (a u exotických jazyků snad i více) byte. To, pochopitelně žere výkon počítače a občas se vloudí podobná chyba, na kterou jsem narazil já. Pokud je to normálně, tak prostě stačí skok o 1000 byte.
Stejné problémy má s texty v utf8 i Midnight Commander, alespoň jsem se s tím opakovaně setkal. Prostě kooperace mezi utf8 a jednobajtovými systémy kódování písmen není stoprocentní.

Jak se mohlo kódování projevit při překopírování do Libreoffice tedy nechápu, ale na 99% je to problém mezi klávesnicí a židlí (resp. ještě jinak: kdyby náš dokumentační tým řešil takové s prominutím kraviny, tak by si nevydělal ani na slanou vodu :-) a to komunikují s celým světem a taky přebírají různé formáty s výstupem do DocBooku (TeX je již z principu slepá ulička, takže ten je jen součástí toolchainu úplně na konci).

A ano, UTF-8 je transformation format, pokud někdo potřebuje (skutečně potřebuje?) práci s jednotlivými znaky, je zde UCS, pořád ale výhody převažují nad touto relativně malou nevýhodou, která je navíc řešena knihovnami.

Prostě po překopírování zdrojového textu z TeXu v iso-8859-2 v gedit do libreoffice na některých místech se úkony jako mazání nebo vkládání znaků děly nalevo od kurzoru. Jev jsem pozoroval jen na některých místech textu a tam, kde se vyskytoval, byl na různých místech řádku různě intenzívní (= počet znaků mezi kurzorem a místem akce byl různě velký). Neprocházel jsem celý text, jen místa, kde byly TeXové tagy, jako uvozovky apod.

Jinak bych si dovolil oponovat názoru, že je TeX slepá ulička, a to ze dvou důvodů:
1. Neexistují jiné rozumně dostupné nástroje, kterými lze udelat text v presentační kvalitě; výsledkem činnosti nástrojů typu "office" je prostě typografický šit
2. Je jednoduchý a funguje bez nutnosti nějakého výkonného HW (s výjimkou zpracování dokumentů s velkoplošnými bitmapovými obrázky o vysoké kvalitě, tam se výkon HW projeví jednoznačně)

Opakovaně jsem se setkal s epub dokumenty, které byly nečitelné v FBReaderu a nešly ani načíst do Libreoffice - jeden příklad jsem uvedl zde v diskusi, časopis Gliese. Z tohoto důvodu považuji tento a podobné formáty za nespolehlivé, jimž je lépe se vyhnout.

Nene, to je nedorozumění, možná jsem to napsal blbě, TeX samozřejmě význam pořád má a jen tak ho neztratí!
Slepá ulička = TeX máme na konci toolchainu při generování PDF. To znamená, že původní dokumenty jsou buď v DocBooku nebo AsciiDocu, renderování HTML je jasné a při požadavku na PDF se použije TeX. Tj. autoři se se zdrojákem v TeXu nesetkají (což skutečně nemá význam, i když LaTeX uznávám), .tex jsou generovány automaticky.

Nojo, jenže jednobajtové kódování nedostačovalo už v osmdesátých letech, a pro komunikaci mezi platformami je UTF-8 ideální, už kvůli endianitě. A do paměti se dá načíst jako wchar_t, přičemž k posunu o 1000 znaků stačí skočit o sizeof(wchar_t)*­1000, ne?
Navíc UTF-8 zvládnou zpracovat jakkoliv staré programy, i když s občasnými problémy, zatímco UTF-16 je pro ně lok vitriolu. Natož UTF-32 ;-)

Oh, ta trojka je tedy síla, snad jen tolik, že PDF skutečně není formát e-booku. Možná, možná a čistě teoreticky Tagged PDF, ale ten prakticky nikdo neumí zpracovat.

To by mě tedy zajímalo, kdo dnes ještě bere knížky v PDF produkované TeXem s tím, že žádný jiný formát není k dispozici.

Vzhledem k výše uvedeným negativním zkušenostem s epub, mobi a pod. opravdu dávám pro čtení na počítači přednost pdf.
Na druhé straně u toho pdf má autor vcelku jistotu, že mu jeho dílo nějaký projekt šíleného programátora nepomrví.

Ad: "To je podstatně méně pohodlné a rychlé než stisknout více kláves současně."

není pravda, kombinace prefix+nějaká klávesa (klávesy) je rychlejší než hledat nějaké přeřaďovače, které nejsou pro psavce všemi deseti na zrovna nejlepších místech.

Ad: "Navíc se mi nikde v dokumentaci k vim nepodařilo najít, jak makra uložit jako soubor na disk a opět nahrát (nezdokumentovaná, špatně zdokumentovaná funkce = neexistující funkce)."

To mě tedy osobně dost překvapuje, protože Vim (a samozřejmě Emacs) mají jednu z nejlepších dokumentací vůbec.

Jinak mapování funguje pro Ctrl+klávesa, v GUI i pro Alt+klávesa (v terminálu záleží na nastavení, to je však problém konfigurace terminálu a ne Vimu).

Navíc pokud nestačí varianty :map tak na některé věci slouží digraphs, málo známá a přitom skvělá fíčurka.