> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/cs/clanky-do-hloubky/54-what-is-a-tex-token-list.md). # Co je seznam TeXových tokenů ## Tak tedy, co přesně je „seznam tokenů TeXu“? V [předchozí článek](/latex/cs/clanky-do-hloubky/53-what-is-a-tex-token.md)—také součást tohoto [série o nízkoúrovňových TeXových technikáliích](/latex/cs/clanky-do-hloubky/01-a-new-series-of-articles-tex-tokens-and-related-concepts-but-why-and-how.md)—zkoumali jsme procesy, kterými TeX prohledává váš `.tex` soubor a vytváří nové tokeny: zkoumali jsme základní podstatu tokenu TeXu a jak je TeX vytváří (viz [Co je „TeX token“?](/latex/cs/clanky-do-hloubky/53-what-is-a-tex-token.md)). V tomto navazujícím článku se podíváme na *seznam tokenů*s: co jsou a jak je TeXové enginy vytvářejí/používají. Získat porozumění seznamům tokenů může být záludné, protože jsou uloženy hluboko uvnitř interních struktur TeXu: tyto detaily jsou uživateli skryté—i když dnes to ne vždy platí, pokud děláte pokročilejší programování s LuaTeXem. Zatím si ale můžete začít představovat seznamy tokenů jako TeXův způsob ukládání řady celočíselných hodnot, přičemž každé celé číslo je token odvozený ze znaku nebo příkazu, který TeX přečetl z vašeho vstupního souboru. Seznamy tokenů hrají klíčovou roli ve vnitřním fungování TeXu, často i poněkud překvapivě, například při vnitřním fungování příkazů jako `\uppercase` a `\lowercase`. Jedno obzvlášť důležité použití seznamů tokenů je ukládání a spouštění maker, což téma podrobně probereme v budoucím článku této série. ### TeX získává svůj vstup ze souborů a seznamů tokenů TeXové enginy mají tři zdroje vstupu—dva možná znáte: * fyzické textové soubory uložené na disku; * text, který uživatel zadává do terminálu (příkazové řádky); ale má také třetí způsob čtení/získávání vstupu: seznamy tokenů! Seznamy tokenů jsou ve skutečnosti vnitřním úložištěm dat, které TeX používá jako součást svého fungování. Protože seznamy tokenů TeXu slouží jako „úložiště“ pro dříve vytvořené tokeny, dává smysl, aby je TeX mohl znovu použít jako další zdroj vstupu. Jakmile je nutné číst další vstup z určitého seznamu tokenů (nebo je k tomu TeX přikázán), TeX dočasně přestane číst vstup z fyzického souboru (tj. vytvářet *nové tokeny*) a přepne na získávání vstupu z *existujících tokenů*: místa v paměti, kde je seznam tokenů uložen. Je zřejmé, že u seznamu tokenů už proces skenování + vytváření tokenů proběhl, takže TeXu stačí podívat se na každý token v seznamu a rozhodnout, co s ním udělá. Na rychlém příkladu, nízkoúrovňový (TeXův primitivní) `\toks` příkaz vám umožní vytvořit seznam tokenů, který si TeX uloží do paměti pro pozdější opětovné použití: ```latex \toks100={Hello} ``` Chcete-li tyto tokeny načíst (tj. říct TeXu, aby je považoval za svůj další zdroj vstupu), zadali byste příkaz jako ```latex \the\toks100 ``` To způsobí, že TeX přepne z vytváření nových tokenů z vašeho vstupního souboru na získávání dalšího vstupu z místa, kde jsou tyto tokeny (vytvořené příkazem `\toks`) uloženy—v tzv. *tokenového registru* , což je jen interní paměťové umístění známé TeXu (zde je to registr 100). Kromě toho mohou být seznamy tokenů interně generovány za běhu řadou TeXových příkazů. Jedním příkladem je příkaz `\jobname` který vytváří řadu znakových tokenů—jeden token pro každý znak v názvu hlavního souboru, který TeX zpracovává. Dalším příkladem je `\string` příkaz; například ```latex \string\mymacro ``` vytváří řadu znakových tokenů pro každé písmeno v názvu `\mymacro`—včetně počátečního `\` znaku. Na některé „příkazy generující tokeny“ se podíváme podrobněji na konci tohoto článku. ## Seznam tokenů: vysvětleno analogií Pokud nemáte programátorské zázemí a/nebo nějaké znalosti informatiky, mohou být „seznamy tokenů“ poněkud mlhavý pojem a možná i trochu matoucí. Pokud se však chcete stát zdatnými ve psaní maker v TeXu/LaTeXu, pak se dobré porozumění tématům jako tokeny TeXu, seznamy tokenů a kategorizační kódy (`\catcode`) bude nesmírně užitečné. V této části použijeme analogii k vysvětlení/ilustraci základních myšlenek/principů seznamu tokenů v TeXu: jak TeX ukládá tokeny do paměti. Stojí za to si to přečíst pozorně, protože seznamy tokenů jsou *zásadním* aspektem TeXu a stojí za to jim porozumět o něco podrobněji. ### Seznamy tokenů: analogie (myšlenkový experiment) Projdeme si „myšlenkový experiment“, který poskytne základ pro pochopení seznamů tokenů v TeXu. Představte si, že máte přístup k velkému množství kontejnerů, například stovkám plechovek—nemůžeme použít termín „krabice“ k popisu našich kontejnerů v myšlenkovém experimentu, protože slovo „krabice“ má v TeXu samozřejmě velmi specifický význam, který s naší diskusí nesouvisí. Budeme tedy naše kontejnery nazývat „plechovky“, přičemž každá plechovka: * má na vnější straně vytištěné jedinečné identifikační číslo; * je (uvnitř) rozdělena na dva oddíly. Tyto dva oddíly jsou navrženy takto: * levý oddíl obsahuje předmět, který chcete do plechovky vložit; * pravý oddíl je určen k uložení kousku papíru, na který můžete napsat jediné číslo: číslo identifikující jinou plechovku. ![test](/files/c969754a15d0cc6cc3ee47b6e0a64e009085703c) Předpokládejme, že máte sbírku třeba 5 předmětů a chcete tuto sbírku uložit do těch plechovek; jenže každý kontejner může pojmout pouze 1 předmět typu, který chcete ukládat. Pro jednoduchost předpokládejme, že chceme uložit 5 barevných koleček: ![{{{alt}}}](/files/ab092a398f5a5d5f3168862fa5dec27ef5d0c294) Navíc, když se vrátíte, abyste tyto předměty ze svého úložiště (plechovek) vyzvedli, tyto předměty *musí* musí být vyzvednuty/nalezeny v určitém pořadí—v pořadí, v jakém byly uloženy: tato posloupnost musí být zachována. Jak toho můžete dosáhnout? Můžeme využít toho, že každá plechovka: * má na vnější straně připevněné jedinečné identifikační číslo; * má 2 oddíly—jen jeden z nich použijeme k uložení našeho předmětu, druhý obsahuje kousek papíru s číslem jiné plechovky napsaným na něm. Budeme předpokládat, že každá plechovka je prázdná—ale nic vám nebrání otevřít libovolnou plechovku a zkontrolovat, zda je prázdná; pokud není, zkuste další, dokud nenajdete prázdnou. Mohli bychom to udělat takto. Vložíme náš první předmět (tmavě zelené kolečko) do jedné z našich plechovek (např. plechovky 124) a poznačíme si číslo této první plechovky—to nevadí, jaké číslo tato první plechovka má, důležité je jen to, abychom si ho někde zapsali a uložili pro pozdější použití. ![{{{alt}}}](/files/684bb6f400e25a2e283357be4767fdfa8fd286c1) Najdeme druhou plechovku—jakékoli číslo plechovky (např. plechovku 432)—a poznamenáme si její číslo. Číslo této druhé plechovky (432) napíšeme na kus papíru a tento lístek vložíme *do první plechovky* (plechovky 124). Do druhé plechovky vložíme náš druhý předmět (světle zelené kolečko). Takže nyní máme tuto situaci: * napsaný lístek—neuložený v plechovce—uvádějící, že první plechovka má číslo 124 (obsahuje náš první předmět); * uvnitř plechovky 124 jsme přidali další poznámku, která říká, že další předmět je třeba hledat v plechovce 432. V podstatě jsme *propojili* naše první dvě plechovky: víme, kde začít (plechovka 124), a poznámka v plechovce 124 nám říká, která plechovka obsahuje další předmět (plechovka 432). ![{{{alt}}}](/files/2cd374f2d12f9311d36b4f97103a15abf45ed33b) Pak najdeme třetí plechovku, její číslo (např. plechovka 543) napíšeme na kus papíru a ten vložíme do *druhé* plechovky (číslo 432). Poté vložíme náš třetí předmět (červené kolečko) do třetí plechovky. Nyní jsme propojili tři plechovky v pořadí: náš výchozí bod, plechovka 124 (tmavě zelené kolečko) → plechovka 432 (světle zelené kolečko) → plechovka 543 (červené kolečko) →… ![{{{alt}}}](/files/159b18821e0ce6c3d624e273d4bd94efb7cf66f4) Tento proces zopakujeme pro poslední dva předměty (světle modré a tmavě modré kolečko) pomocí plechovky 213 (světle modré kolečko) a plechovky 102 (tmavě modré kolečko). ![{{{alt}}}](/files/8435d458fe531f0355d9ec47229df4918ebab9bb) Nyní máme všech 5 plechovek propojeno (pomocí číselného identifikátoru každé plechovky) a můžeme vyzvednout všechny uložené předměty—ve správném pořadí—prostým navštívením každé plechovky po řadě, vyjmutím našeho předmětu a podíváním se na poznámku, která nám říká, ve které plechovce je náš další předmět. ### A co poslední předmět v našem seznamu (plechovka 102)? Proč bychom se měli zabývat právě tímto? Zatím jsme uložili každý předmět do plechovky spolu s poznámkou, která říká, která plechovka obsahuje další předmět: co by měla tato poznámka říkat u posledního předmětu v našem seznamu—protože žádná další plechovka není. Když dojdeme k poslednímu předmětu (plechovce), musí být zřejmé, že tato plechovka (obsahující poslední předmět) je posledním prvkem našeho seznamu—nemusíme hledat další plechovku, protože žádná neexistuje. Jeden ze způsobů, jak toho dosáhnout, je vložit do naší poslední plechovky (102) „speciální“ číslo plechovky. Můžeme použít libovolné číslo, pokud zvolíme jedinečné číslo, které není číslem skutečné plechovky—například „plechovka -1“, „plechovka 0“: nezáleží na tom, dokud víme, že „plechovka -1“ nebo „plechovka 0“ atd. nám okamžitě říká, že máme přestat hledat: nemusíme hledat žádné další plechovky, protože toto je ta poslední, a tedy už nejsou žádné další předměty k vyzvednutí. ### Od „předmětů“ a „plechovek“ k tokenům a TeXu Nyní se musíme přesunout od naší analogie k popisu, který je blíž realitě TeXu. Za prvé, místo ukládání různobarevných koleček do našich pomyslných plechovek by mělo být jasné, že bychom mohli na tyto plechovky nahlížet jako na ukládání tokenů TeXu: jednoduchých celých čísel. To je ta snazší část převodu naší analogie do oblasti softwaru (TeXu). Ale jaký by mohl být softwarový ekvivalent našich fyzických očíslovaných plechovek s „oddíly“? Nechceme zacházet příliš daleko do programovacích pojmů, ale můžete na naše „plechovky“ nahlížet jako na několik bajtů paměti počítače, které byly „zabaleny“ do pohodlné jednotky úložiště. Použití číselného identifikátoru pro každou plechovku lze chápat jako umístění uvnitř paměti počítače, kde je každý malý balíček paměti uložen. V samotném TeXu se těmto malým balíčkům úložiště říká „paměťová slova“—pojem odrážející dobu/éru, ve které TeX vznikl (70. léta). Tato „paměťová slova“ jsou základním stavebním prvkem používaným v TeXu, ale zde je nemusíme podrobněji rozebírat—kdo chce více podrobností, může se podívat na článek na [autorově osobním blogu](http://www.readytext.co.uk/?p=3537). V terminologii počítačového programování se tomu, o čem jsme mluvili, říká [*spojový seznam*](https://en.wikipedia.org/wiki/Linked_list): seznam tokenů TeXu je zřetězený seznam vytvořený z TeXových paměťových kontejnerů nazývaných *paměťová slova* kde každé paměťové slovo může sloužit k uložení: * a *hodnota*: hodnota tokenu (celé číslo); * a *odkaz*: paměťové umístění dalšího paměťového slova obsahujícího další token v našem seznamu. ## Kde TeX používá seznamy tokenů? Všude! Je to tak, protože definice makra TeXu/LaTeXu (např. příkaz LaTeXu) je uložena jako (mírně specializovaná) forma seznamu tokenů—specializovaná v tom smyslu, že obsahuje tokeny, které v „běžných“ seznamech tokenů neuvidíte (související s přiřazováním parametrů makra atd.). Netrapte se tím, protože tyto detaily probereme v budoucím článku. ### Příklad makra Makro si lze představit jako složené ze tří částí: ``` \def\{} ``` Všimněte si, že místo `\def` byste mohli použít `\edef`, `\gdef` nebo `\xdef`. **Poznámka pro uživatele LaTeXu**: Zde definujeme makra pomocí syrových, nízkoúrovňových TeXových příkazů (nazývaných *primitivy*). Uživatelé LaTeXu budou více znát vytváření maker pomocí LaTeXového `\newcommand` (který je sám makrem). Když požádáte TeX, aby vytvořil (definoval) makro, vytvoří token, který představuje `` a *seznam tokenů* který představuje spojený `` a ``. TeX pečlivě uloží vše tak, aby token představující `` je propojen se seznamem tokenů představujícím jeho definici (`` a ``). Například, pokud definujeme `\mymacro` takto: ```latex \def\mymacro abc #1 defz{I typed "#1"!} ``` Vidíme, že jeho jednotlivé části jsou: * `` = `mymacro` * `` = `abc #1 defz` * `` = `I typed "#1"!` Například byste mohli zavolat `\mymacro` takto: ```latex \mymacro abc THIS TEXT defz ``` což vede k tomu, že `I typed "THIS TEXT"!` je vysázeno— `abc` a `defz` jste *ne* vysázeno. `abc` a `defz` jsou posloupnosti znakových tokenů používané k *vymezení* parametru makra `#1` a jsou pohlceny a zahozeny, když je vaše volání makra úspěšně zpracováno TeXem. Když jste definovali `\mymacro`, slouží vzor tokenů obsažený v uloženém seznamu jako „šablona“, kterou může TeX použít k určení: * které tokeny ve vašem vstupu jsou oddělovací tokeny; * které tokeny ve vašem vstupu skutečně tvoří parametr(y) vašeho makra (zde to, co používáte pro `#1` ve vašem volání `\mymacro`). Musíte volat `\mymacro` za `` s oddělovači, které jsou totožné s těmi, které byly použity k jeho definici—to zahrnuje i použití znakových oddělovačů se shodnými kategoriovými kódy. Pokud jsou oddělovače v `` použité pro volání `\mymacro` odlišné od těch, které byly použity k jeho definici („šablona“ uložená v paměti), může být TeX dost zmatený—když se pokouší zpracovat `\mymacro` nedokázal by přiřadit „šablonu“, kterou má uloženou v paměti. Když TeX uvidí, že voláte makro, prohledá váš vstupní text, aby vytvořil nové tokeny, a bude se je, token po tokenu, snažit porovnat se seznamem tokenů `` který je uložen jako součást definice vašeho makra. Pokud oddělovače použité ve vašem vstupním textu vedou k posloupnosti tokenů, které neodpovídají těm uloženým v „šabloně“, TeX obvykle vyhodí chybu. TeX je velmi striktní—pamatujte, že znakové tokeny jsou kombinací znakového kódu a kategoriového kódu: pokud změníte kategoriový kód znaku, získáte z toho znaku jinou hodnotu tokenu. Představme si, že bychom změnili kategoriový kód `z` na třeba 12—běžně je 11—a zkusili naše makro zavolat takto: ```latex \catcode`z=12 \mymacro abc THIS TEXT defz more text here... ``` Tentokrát to nebude fungovat, protože kategoriový kód `z` se změnil. Uvidíte chybu jako je tato: ```latex Uteklý argument? TENTO TEXT defz ! Odstavec skončil dříve, než bylo \mymacro dokončeno. \par ř.22 ``` Když TeX čte a prohledává `z` v `defz` nemůže rozpoznat, že tvoří konec `\mymacro`’s `` použitého ve vašem vstupním souboru. Až do okamžiku, než narazí na tento chybný `z` TeX správně porovnal první 3 znaky `def` ale to `z` (s kategoriovým kódem 12) zamotá TeXu prohledávání. Předpokládejme, že `z` měl kategoriový kód 11, když jsme *definovali* `\mymacro`: to by vedlo k tomu, že by se jako součást `\mymacro`definice (tj. uložené jako součást „šablony“). Avšak s kategoriovým kódem 12, `z` vytvoří nyní hodnotu tokenu 256×12 + 122 = 3194. Protože hodnota tokenu (pro `z`) přečtená z vašeho vstupu (hodnota 3194) neodpovídá `z`-tokenu obsaženému v uložené `` šabloně seznamu tokenů (hodnota 2938), TeX bude pokračovat v prohledávání vašeho vstupu. TeX bude dále skenovat text následující za vaším makrem (*další text zde* …) a hledat další tokeny—pokusí se porovnat uloženou šablonu s tokeny, které ve vašem vstupu najde. Pravděpodobně nenajde správný vzor tokenů a vzniknou chyby, protože TeX „přestřelí“ váš vstup a mylně přečte další text, aby vytvořil další tokeny—tyto další tokeny neměly být v tomto bodě přečteny a téměř jistě vyvolají chybu. Podrobněji se tomu budeme věnovat v budoucím článku. ## Další použití seznamů tokenů Mezi další příkazy používané k vytváření/ukládání seznamů tokenů patří: ```latex \toks={...} \everypar={...} \everymath={...} \everydisplay={...} \everyhbox={...} \everyvbox={...} \output={...} \everyjob={...} \everycr={...} \errhelp={...} ``` Každý z těchto příkazů vytvoří ze znaků a příkazů uvnitř složených závorek „{...}“ seznam tokenů a tento seznam tokenů je určen k opětovnému použití za určitých okolností. Například `\everypar={...}` vytvoří a uloží sadu tokenů (seznam tokenů), kterou TeX vloží do vstupu těsně předtím, než začne nový odstavec. ## Skrytá použití seznamů tokenů: příklady V této závěrečné části se podíváme na některé praktické příklady použití seznamů tokenů způsobem, který možná nečekáte. ### Příklad 1: \uppercase{...} a \lowercase{....}—dočasné seznamy tokenů Kromě výslovných příkazů pro generování seznamů tokenů existují okolnosti, kdy TeX vytvoří skrytý a dočasný interní seznam tokenů, aby provedl nějaké zvláštní zpracování. Pamatujte, že když TeX čte/zpracovává vaše vstupní znaky/příkazy, přemění je na tokeny: základní stavební kameny, se kterými TeXové enginy pracují. Dobrým příkladem jsou příkazy `\uppercase{...}` nebo `\lowercase{...}` protože jejich činnost může být při prvním setkání docela matoucí. Jakmile pochopíte, co dělají—hlouběji uvnitř TeXu a neviditelně pro uživatele—stane se jejich fungování mnohem snáze pochopitelné. Představte si, že máte jednoduchou řadu písmen, která chcete převést na velká—např. abcde na ABCDE. S TeXovým `\uppercase` příkazu: ```latex \uppercase{abcde} ``` způsobí, že TeX vypíše `ABCDE`. Nyní předpokládejme, že bychom si chtěli naši jednoduchou řadu písmen uložit pro pozdější použití—tj. nechceme je hned vypsat, takže použijeme jediné TeXovo *interní* mechanismus—nikoli externí (souborový) mechanismus—pro ukládání dat: použijeme seznam tokenů. Můžeme to udělat buď vytvořením makra, nebo použitím explicitního příkazu seznamu tokenů: ```latex \toks100={abcde} \def\mychars{abcde} ``` Potom se možná v určité chvíli rozhodnete, že byste rádi svou řadu písmen znovu použili, ale tentokrát velkými písmeny; takže zkusíte ```latex \uppercase{\the\toks100} ``` a ```latex \uppercase{\mychars} ``` Jenže bohužel ani jeden z těchto pokusů nefunguje. Proč? ### Tajné seznamy tokenů! Abychom pochopili, jak příkazy `\uppercase{...}` `\lowercase{...}` ve skutečnosti fungují, musel jsem nahlédnout dovnitř vnitřního fungování TeXu, takže následující vysvětlení z toho vychází. Když TeX detekuje buď `\uppercase{}` nebo `\lowercase{}` ve vašem vstupu, první věc, kterou TeX udělá, je vytvořit (dočasný) interní seznam tokenů z `` uzavřeného mezi ‚{‘ a ‚}‘, které následují po `\uppercase{...}` nebo `\lowercase{...}` příkazech—tento dočasný seznam tokenů je interní záležitostí TeXu. Klíčovým bodem, zásadním pro pochopení toho, jak `\uppercase{}` a `\lowercase{}` ve skutečnosti fungují, je to, že jakékoli příkazy nebo makra obsažené v `` nejsou *rozbalen*: TeX pouze generuje tokeny ze znaků a příkazů umístěných mezi `{...}`. Během fungování `\uppercase{}` nebo `\lowercase{}` se nic uvnitř závorek nespouští: jednoduše se to převede na tokeny. Po `` uvnitř `{...}` byl převeden na (dočasný) seznam tokenů, TeX se pak znovu podívá na každý token v tomto seznamu a otestuje, zda je *znaku* token nebo *příkaz* token (použitím číselné hodnoty tokenu). Pokud TeX zjistí znakový token, upraví tento token tak, aby změnil velikost písmene znaku (podle toho, zda `\uppercase` nebo `\lowercase` se zpracovává). TeX jednoduše ignoruje všechny tokeny příkazů a „nedívá se dovnitř“ žádných tokenů příkazů, aby zjistil, co představují nebo obsahují (např. makro obsahující znaky)—jednoduše je přeskočí: operacemi měnícími velikost písmen jsou ve skutečnosti zpracovávány/ovlivňovány pouze znakové tokeny. Takže například, když zadáme TeXový příkaz jako `\uppercase{abcde}` TeX vytvoří seznam tokenů z `abcde` obsahující pouze znakové tokeny: všechny jsou upraveny tak, aby vytvořily řadu změněných tokenů představujících A, B, C, D a E. Tyto změněné tokeny jsou vráceny zpět do TeXova zpracování vstupu, což vede k tomu, `ABCDE` že se vysází. Pokud jsme však naše znaky uložili *uvnitř makra*—například `\def\mychars{abcde}`—a pokusíme se je převést na velká písmena takto: ```latex \uppercase{\mychars} ``` pak to selže a vysází se abcde—nikoli ABCDE, jak byste možná čekali. Pokud se pak pokusíme uložit naše znaky do seznamu tokenů, například `\toks0={abcde}` a provedeme `\uppercase{\the\toks0}` pak znovu `\uppercase` to selže, protože seznam tokenů bude tvořen výhradně tokeny, které nejsou ovlivněny `\uppercase`. Na příkladu našeho makra, `\mychars`, po tom, co TeX detekuje `\uppercase` ve vstupu, TeX si vyhledá význam `\uppercase` a provede jej, čímž vytvoří dočasný seznam tokenů z `{\mychars}`. Je zřejmé, že tento dočasný seznam tokenů obsahuje jen jeden token, který není znakový token, ale ten, který představuje náš příkaz makra `\mychars`: proto je pro účely provádění `\uppercase`, tento token ignorován—`\mychars` nepředstavuje znakový token. Avšak jak bylo uvedeno výše, jakmile `\uppercase` splní svou práci, dočasný seznam tokenů (vytvořený činností `\uppercase`) je vrácen zpět do úplného TeXova mechanismu zpracování vstupu (skenování). Když TeX tento seznam tokenů znovu přečte, zjistí token, který představuje naše `\mychars` makro, které TeX provede (expanduje) a vygeneruje řadu znaků pro vysázení abcde—stále malými písmeny, protože byly „zabaleny“ uvnitř makra, a jsou tedy neviditelné pro účinky `\uppercase`. Jakmile TeX znovu prozkoumá dočasný seznam tokenů vytvořený pro `\uppercase{...}` nebo `\lowercase{...}`, a zpracuje případné znakové tokeny, přepne na používání tohoto dočasného seznamu tokenů jako svého zdroje vstupu: sazbu znaků (zpracovaných znakových tokenů) a vykonávání příkazů a maker. ### Jak to lze napravit? Protože `\uppercase{...}` nebo `\lowercase{...}` bude působit jen na znakové tokeny, potřebujeme způsob, jak „vynutit rozbalení“ znaků obsažených v našem makru `\mychars` (nebo obsažených v `\toks` registru) předtím, než `\uppercase{...}` nebo `\lowercase{...}` na něm začne pracovat. Tím „rozbalením“ myslíme ve skutečnosti TeXův proces *rozšiřování*: * nahrazení příkazu TeXu/LaTeXu *posloupností* tokenů *ze kterých je tento příkaz* (*např. makro*) *složen,* nebo * a tím se vytvoří posloupnost tokenů, kterou má příkaz za úkol *generovat*. Jedním příkladem příkazu, který generuje tokeny, je `\jobname`, který vytváří posloupnost znakových tokenů představujících název hlavního TeXového souboru, který se zpracovává. #### Nízkoúrovňová magie: scantoks(..., ...) Zde už skutečně nahlížíme do temnějších zákoutí vnitřního fungování TeXu, takže tuto část můžete ignorovat, pokud vás detaily nebaví… Poté, co TeX detekuje `\uppercase` nebo `\lowercase` ve vstupním proudu, spustí interní funkci nazvanou `scantoks(..., ...)` jejímž úkolem je vytvořit seznam tokenů pomocí položek mezi otevírací ‚{‘ a zavírací ‚}‘—jak bylo řečeno, tento seznam tokenů je následně prozkoumán, aby se odhalily (a pak upravily) případné znakové tokeny tak, aby se podle potřeby změnilo velikost písmen znaků. Všimněte si pečlivě, že mluvíme o `scantoks(..., ...)` jako o interní funkci zabudované do zdrojového kódu TeXových enginů—zde se nemíní jako název řídicí sekvence. V rámci své činnosti `scantoks(..., ...)` lze zadat, zda má rozšiřovat, nebo nerozšiřovat, seznam tokenů, který vytváří, a pro `\uppercase` a (`\lowercase`) tokeny nerozšiřuje: pouze je vytvoří a vloží do seznamu tokenů. Jedna z prvních věcí, které `scantoks(..., ...)` musí udělat, je zkontrolovat otevírací ‚{‘ (nebo jakýkoli znak s `\catcode` kategoriovým kódem 1), protože musí zajistit, že uživatel neudělal syntaktickou chybu a nezapomněl na otevírací ‚{‘ (nebo jakýkoli znak s kategoriovým kódem 1)—protože znak s kategoriovým kódem 1 je nutný k vymezení začátku seznamu položek, které mají být tokenizovány. A tady je ten trik: úkol hledání otevírací ‚{‘ spustí `scantoks(..., ...)` spuštění expanzního procesu TeXu, což znamená, že následující příklady budou fungovat: ```latex \let\ob={ \uppercase\ob abcde} \def\obb{\ob} \uppercase\obb xyz} ``` Na příkladu `\obb`, makra, je rozpoznáno jako *rozšiřitelný příkaz* a TeX je náležitě expanduje (prostřednictvím `scantoks(..., ...)` funkce) při hledání otevírací závorky (jakéhokoli znaku s kategoriovým kódem 1). To znamená, že můžeme použít „`\expandafter` trik“ k dosažení našeho cíle „rozbalit“ naše znaky z omezení makra—tj. expandovat je. Všimněte si, že `\expandafter` také spadá do kategorie *rozšiřitelný příkaz*, takže jej zde TeX vykoná a nechá ho dělat svou práci jako součást hledání otevírací ‚{‘ (nebo jakéhokoli znaku s kategoriovým kódem 1). Takže pokud definujete: ```latex \toks0={abcde} \def\mychars{abcde} ``` A uděláte toto: ```latex \uppercase\expandafter{\mychars} \uppercase\expandafter{\the\toks0} ``` v obou případech nyní uvidíte vysázené ABCDE, protože `\expandafter` způsobí „rozbalení“ (expanzi) `\mychars` a `\the\toks0`—v obou případech vede k `\uppercase` tomu, že vidí proud znakových tokenů, který mohou zpracovat a změnit jejich velikost písmen. ### Příklad 2: \string—další dočasné seznamy tokenů Interně TeX klasifikuje `\string` jako jeden ze svých takzvaných „konverzních“ příkazů: provádí operaci „převést na text“. Ta `\string` Příkaz je navržen tak, aby převedl token na textovou verzi čitelnou pro člověka — tj. vysází čitelný řetězec znaků, z něhož byl daný token původně vytvořen. Například `\string\hello` vytvoří dočasný seznam tokenů, který obsahuje znaky \\, h, e, l, l, o — ano, dokonce i včetně počátečního ‚\‘. Jakmile je tento seznam tokenů vytvořen, je poté znovu načten TeXem a text příkazu „`\hello`“ je vysázen — ano, i včetně ‚\‘, pokud zvolíte správné písmo… Možná vás napadne, jak/proč TeX může vysázet znak pro escape, když se obvykle používá k tomu, aby scanneru TeXu spustil vytvoření tokenu příkazu: proč to tady nedělá? Odpověď souvisí s kategoriálními kódy: obvykle má znak ‚\‘ catcode 0 (escape character), ale když `\string` generuje svůj interní seznam tokenů, dělá to trochu jinak. Když vytváří seznam znakových tokenů, přiřadí všem znakům kromě mezery kategoriální kód 12 — mezera dostane catcode 10 — připomeňme, že znakové tokeny se počítají jako 256 × catcode + hodnota ASCII. Takže když TeX znovu čte (vkládá) dočasný seznam tokenů, který `\string` byl vygenerován z `\hello`, TeX *nevidí znak escape* protože token pro ‚\‘ byl vypočten s catcodem 12, a ne 0: TeX prostě zachází s ‚\‘ jako s obyčejným znakem a vysází ho. Přesně vzato bychom měli pravděpodobně poznamenat, že TeX ve skutečnosti negeneruje token pro znaky escape, když je rozpozná ve vstupu. Jakmile rozpozná znak s kategoriálním kódem 0, tento znak se jen použije k „vyvolání“ vytvoření tokenu kontrolní sekvence: jakmile tím přiměje TeX, aby to provedl, znak escape splnil svůj účel a už se dál nebere v úvahu. ### Technická poznámka Příkaz nazvaný `\showtokens{...}` (zavedený enginem e-TeX) může zobrazit seznamy tokenů (v logovacím souboru). Z manuálu e-TeXu: > Příkaz `\showtokens{}` zobrazí seznam tokenů a umožňuje zobrazení hodnot, které nelze zobrazit pomocí `\show` nebo `\showthe`, např.: > > ```latex > \showtokens\expandafter{\jobname} > ``` ## Na závěr V části 291 zdrojového kódu TeXu (viz strana 122 v [TeX: The Program](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373)) Knuth popisuje seznam tokenů takto: > „Seznam tokenů je jednoduše propojený seznam jednoузlových uzlů v paměti, kde každé slovo obsahuje token a odkaz. Definice maker, definice výstupní rutiny, značky, `\write` texty a několik dalších věcí si TeX pamatuje ve formě seznamů tokenů, obvykle předcházených uzlem s počtem referencí v jeho poli „token\_ref\_count“.“ Při prvním čtení to možná nebylo snadné pochopit, ale snad teď to dává o něco větší smysl. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/latex/cs/clanky-do-hloubky/54-what-is-a-tex-token-list.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.