> 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/da/dybtgaende-artikler/54-what-is-a-tex-token-list.md). # Hvad er en TeX-tokenliste ## Så, hvad er egentlig en "TeX-tokenliste"? I en [forrige artikel](/latex/da/dybtgaende-artikler/53-what-is-a-tex-token.md)—også en del af denne [serie om lav-niveau TeX-detaljer](/latex/da/dybtgaende-artikler/01-a-new-series-of-articles-tex-tokens-and-related-concepts-but-why-and-how.md)—vi undersøgte processerne, hvorigennem TeX scanner din `.tex` fil for at generere nye tokens: vi undersøgte den grundlæggende natur af et TeX-token, og hvordan TeX opretter dem (se [Hvad er et "TeX-token"?](/latex/da/dybtgaende-artikler/53-what-is-a-tex-token.md)). I denne opfølgende artikel ser vi nærmere på *tokenliste*er: hvad er de, og hvordan opretter/bruger TeX-motorer dem. Det kan være vanskeligt at få en forståelse for tokenlister, fordi de er gemt dybt inde i TeX’s interne struktur: disse detaljer er skjult for brugeren—selv om det i dag ikke altid er tilfældet, hvis du laver mere avanceret programmering med LuaTeX. Men indtil videre kan du begynde at tænke på tokenlister som TeX’s måde at lagre en række heltalsværdier på, hvor hvert heltal er et token, der stammer fra et tegn eller en kommando, som TeX havde læst fra din inputfil. Tokenlister spiller en afgørende rolle i TeX’s interne funktion, ofte på nogle overraskende måder, såsom den interne funktion af kommandoer som `\uppercase` og `\lowercase`. En særlig vigtig anvendelse af tokenlister er lagring og udførelse af makroer, et emne vi vil undersøge i detaljer som en del af en fremtidig artikel i denne serie. ### TeX får sit input fra filer og tokenlister TeX-motorer har tre inputkilder—to som du måske kender: * fysiske tekstfiler gemt på disken; * tekst, som en bruger skriver ind i terminalen (kommandolinjen); men den har også en tredje måde at læse/få input på: tokenlister! Tokenlister er i praksis et internt datalager, som TeX bruger som en del af sine operationer. Fordi TeX’s tokenlister fungerer som et “lager” for tidligere oprettede tokens, giver det mening, at TeX kan genbruge dem som en anden inputkilde. Når det bliver nødvendigt at tage det næste input fra en bestemt tokenliste (eller TeX får besked på at gøre det), vil TeX midlertidigt standse læsningen af input fra en fysisk fil (dvs. oprette *nye tokens*) og skifte til at hente sit input fra *eksisterende tokens*: den hukommelsesplacering, hvor tokenlisten er gemt. Når tokenlisten bruges, har processen med scanning + generering af tokens tydeligvis allerede fundet sted, så TeX behøver blot at se på hvert token i listen og beslutte, hvad det skal gøre med hver enkelt. By way of a quick example, the low-level (TeX primitive) `\toks` kommandoen lader dig oprette en liste af tokens, som TeX gemmer i hukommelsen til senere genbrug: ```latex \toks100={Hello} ``` For at hente disse tokens (dvs. fortælle TeX, at de skal behandles som dens næste inputkilde) ville du give en kommando som ```latex \the\toks100 ``` Dette vil få TeX til at skifte fra at oprette nye tokens fra din inputfil til at få det næste derfra, hvor disse tokens (oprettet af `\toks`) er gemt—i en såkaldt *tokenregister* som blot er en intern hukommelsesplacering kendt af TeX (her er det register 100). Derudover kan tokenlister genereres internt, løbende, af en række TeX-kommandoer. Et eksempel er kommandoen `\jobname` som genererer en række tegntokens—ét token for hvert tegn i navnet på den hovedfil, som TeX behandler. Et andet eksempel er `\string` kommandoen; for eksempel ```latex \string\mymacro ``` genererer en række tegntokens for hvert bogstav i navnet `\mymacro`—inklusive det indledende `\` tegn. Vi ser nærmere på nogle “token-genererende kommandoer” sidst i denne artikel. ## Tokenliste: forklaret ved analogi Medmindre du har en programmeringsbaggrund og/eller nogen viden om datalogi, kan “tokenlister” være et noget uklart begreb og måske lidt forvirrende. Men hvis du ønsker at blive dygtig til at skrive TeX/LaTeX-makroer, vil en god forståelse af emner som TeX-tokens, tokenlister og kategorikoder (`\catcode`) vise sig at være yderst nyttig. I dette afsnit vil vi bruge en analogi til at forklare/illustrere de centrale idéer/principper i en TeX-tokenliste: hvordan TeX gemmer tokens i hukommelsen. Det er værd at bruge tid på at læse dette igennem, fordi tokenlister er en *grundlæggende* del af TeX og værd at forstå lidt mere detaljeret. ### Tokenlister: En analogi (tankeeksperiment) Vi vil arbejde os gennem et “tankeeksperiment” for at skabe et grundlag for at forstå TeX-tokenlister. Forestil dig, at du havde adgang til et stort sæt beholdere, såsom hundredvis af dåser—vi kan ikke bruge termen “boks” til at beskrive vores tankeeksperimentbeholdere, fordi “boks” naturligvis har en helt specifik betydning i TeX, som ikke har noget med vores diskussion her at gøre. Så vi vil kalde vores beholdere “dåser”, hvor hver dåse: * har et unikt identifikationsnummer trykt udenpå; * er (internt) opdelt i to rum. De to rum er udformet således: * det venstre rum indeholder den genstand, du vil lægge i dåsen; * det højre rum er beregnet til at holde et stykke papir, hvorpå du kan skrive et enkelt tal: nummeret, der identificerer en anden dåse. ![test](/files/c106011a087adafa95d7482e8335cddf4a2f18f9) Antag, at du har en samling på f.eks. 5 genstande, og du vil gemme den samling af genstande i disse dåser; men ak, hver dåse kan kun rumme 1 genstand af den type, du vil gemme. For enkelhedens skyld antager vi, at vi vil gemme 5 farvede cirkler: ![{{{alt}}}](/files/d6509b4bff1629a5172d3ff4e4c4180dffc9874d) Desuden, når du går tilbage for at hente disse genstande fra dit lagersystem (dåser), skal disse genstande *skal* kunne hentes/findes i en bestemt rækkefølge—den rækkefølge, de blev gemt i: denne sekvens skal bevares. Hvordan kan du opnå det? Vi kan udnytte det faktum, at hver dåse: * har et unikt identifikationsnummer fastgjort udenpå; * har 2 rum—hvoraf kun 1 vil blive brugt til at indeholde vores genstand, mens det andet indeholder et stykke papir med en anden dåses nummer skrevet på. Vi antager, at hver dåse er tom—men der er intet til hinder for, at du åbner en hvilken som helst dåse for at tjekke, om den er tom; hvis den ikke er, så prøv den næste, indtil du finder en tom dåse. Det, vi kunne gøre, er som følger. Læg vores første genstand (mørkegrøn cirkel) i en af vores dåser (f.eks. dåse 124) og noter nummeret på denne første dåse—det betyder ikke noget, hvilket nummer den første dåse har, det eneste, der betyder noget, er, at vi skriver det ned et sted og gemmer det til senere brug. ![{{{alt}}}](/files/fbf1dabd65f41a10777f09c0d203b947b8f83191) Find en anden dåse—et hvilket som helst dåsenummer (f.eks. dåse 432)—og noter dens nummer. Skriv nummeret på den anden dåse (432) på et stykke papir og læg den note *i den første dåse* (dåse 124). Vi lægger vores anden genstand (lysegrøn cirkel) i den anden dåse. Så vi har i øjeblikket følgende situation: * en skriftlig note—ikke gemt i en dåse—der angiver, at den første dåse er nummer 124 (den indeholder vores første genstand); * i dåse 124 har vi tilføjet en anden note, der siger, at den næste genstand findes i dåse 432. I bund og grund har vi *kædet* vores første to dåser sammen: vi ved, hvor vi skal starte (dåse 124), og at en note i dåse 124 fortæller os, hvilken dåse der indeholder den næste genstand (dåse 432). ![{{{alt}}}](/files/631b96023ff4e2c9f1624ba2143ee049c8fcd448) Vi finder derefter en tredje dåse, skriver dens nummer (f.eks. dåse 543) på et stykke papir og lægger det i den *anden* dåse (nummer 432). Derefter lægger vi vores tredje genstand (rød cirkel) i den tredje dåse. Nu har vi kædet tre dåser sammen i sekvensen: vores startpunkt, dåse 124 (mørkegrøn cirkel) → dåse 432 (lysegrøn cirkel)→ dåse 543 (rød cirkel) →… ![{{{alt}}}](/files/b194ca74d0d06b9ed1ade71d1c7b83d730858168) Gentag denne proces for de sidste to genstande (lyseblå og mørkeblå cirkler) ved at bruge dåse 213 (lyseblå cirkel) og dåse 102 (mørkeblå cirkel). ![{{{alt}}}](/files/b2abb20a909d5c2758cf34043f4903f694fb9e87) Vi har nu alle 5 dåser kædet sammen (ved hjælp af det numeriske id for hver dåse) og kan hente alle vores gemte genstande—i den korrekte rækkefølge—blot ved at besøge hver dåse efter tur, fjerne vores genstand og se på noten, der fortæller os, hvilken dåse der indeholder vores næste genstand. ### Hvad med det sidste element på vores liste (dåse 102)? Hvorfor skulle vi bekymre os særligt om denne? Indtil videre har vi gemt hver genstand i en dåse sammen med en note, der siger, hvilken dåse der indeholder den næste genstand: for det sidste element på vores liste, hvad skal den note så sige—fordi der ikke findes nogen næste dåse. Når vi når det sidste element (dåse), skal det være tydeligt, at denne dåse (som indeholder det sidste element) er det sidste element på vores liste—vi behøver ikke lede efter en anden dåse, fordi der ikke er nogen. En måde at gøre det på er at placere et “særligt” dåsenummer inde i vores sidste dåse (102). Vi kan bruge et hvilket som helst nummer, vi ønsker, forudsat at vi vælger et unikt nummer, som ikke er nummeret på en faktisk dåse—for eksempel “dåse -1”, “dåse 0”: det er ligegyldigt, så længe vi ved, at “dåse -1” eller “dåse 0” osv. straks fortæller os, at vi skal stoppe med at lede: vi behøver ikke lede efter flere dåser, fordi dette er den sidste, og derfor er der ingen flere genstande at hente. ### Fra “genstande” og “dåser” til tokens og TeX Vi skal nu bevæge os fra vores analogi til en beskrivelse, der ligger tættere på TeX’s virkelighed. For det første burde det være klart, at i stedet for at gemme forskelligt farvede cirkler i vores imaginære dåser kunne vi tænke på disse dåser som lagrende TeX-tokens: simple heltal. Det er den lettere del af at overføre vores analogi til softwareverdenen (TeX). Men hvad kunne være softwareækvivalenten til vores fysiske nummererede dåser med “rum”? Vi vil ikke gå alt for langt ind i programmeringsbegreber, men du kan tænke på vores “dåser” som repræsenterende nogle få bytes computerhukommelse, som er blevet “pakket” sammen til en praktisk lagringsenhed. Vores analogis brug af et numerisk id for hver dåse kan betragtes som den placering inde i computerhukommelsen, hvor hver lille hukommelsespakke befinder sig. Inde i selve TeX kaldes disse små lagringspakker for “memory words”—et udtryk, der afspejler den tid/epoke, hvor TeX blev skabt (1970’erne). Disse “memory words” er den grundlæggende byggesten, som bruges i TeX, men vi behøver ikke at udforske dem yderligere her—den, der ønsker flere detaljer, kan henvise til en artikel på [forfatterens personlige blog](http://www.readytext.co.uk/?p=3537). I datalogiske termer kaldes det, vi har diskuteret, en [*kædet liste*](https://en.wikipedia.org/wiki/Linked_list): en TeX-tokenliste er en kædet liste bygget af TeX’s lagringsbeholdere kaldet *hukommelsesord* hvor hvert hukommelsesord kan bruges til at lagre: * a *værdi*: tokenets værdi (et heltal); * a *peger*: hukommelsesplaceringen for det næste hukommelsesord, der indeholder det næste token i vores liste. ## Hvor bruger TeX tokenlister? Overalt! Det er sandt, fordi en TeX/LaTeX-makrodefinition (f.eks. en LaTeX-kommando) gemmes som en (lidt specialiseret) form for tokenliste—specialiseret i den forstand, at den indeholder tokens, som du ikke ser i “standard” tokenlister (relateret til matchning af makroparametre osv.). Bare rolig, vi tager os af de detaljer i en fremtidig artikel. ### Et eksempel på en makro En makro kan opfattes som bestående af tre dele: ``` \def\{} ``` Bemærk, at i stedet for `\def` kunne du have brugt `\edef`, `\gdef` eller `\xdef`. **Bemærkning til LaTeX-brugere**: Her definerer vi makroer ved hjælp af rå, lavniveau TeX-kommandoer (kaldet *primitiver*). LaTeX-brugere vil være mere fortrolige med at oprette makroer via LaTeX’s `\newcommand` (som i sig selv er en makro). Når du beder TeX om at oprette (definere) en makro, vil den oprette et token, der repræsenterer `` og en *tokenliste* som repræsenterer den samlede `` og ``. TeX vil omhyggeligt gemme alt, så tokenet, der repræsenterer `` er kædet til tokenlisten, der repræsenterer dens definition (`` og ``). Hvis vi for eksempel definerer `\mymacro` som dette: ```latex \def\mymacro abc #1 defz{I typed \"#1\"!} ``` Vi kan se, at dens bestanddele er: * `` = `mymacro` * `` = `abc #1 defz` * `` = `Jeg skrev \"#1\"!` For eksempel kunne du kalde `\mymacro` som dette: ```latex \mymacro abc THIS TEXT defz ``` hvilket resulterer i `Jeg skrev \"THIS TEXT\"!` blive sat op— `abc` og `defz` er *ikke* sat op. `abc` og `defz` er sekvenser af tegntokens, der bruges til at *afgrænse* makroparameteren `#1` og absorberes og kasseres, når dit makrokald behandles korrekt af TeX. Når du definerede `\mymacro`, fungerer tokenmønstret i det gemte som en “skabelon”, som TeX kan bruge til at finde ud af: * hvilke tokens i dit input der er afgrænsningstokens; * hvilke tokens i dit input der faktisk udgør parameteren/parametrene for din makro (her, det du bruger til `#1` i dit kald af `\mymacro`). Du skal kalde `\mymacro` med en `` med afgrænsere, der er identiske med dem, der blev brugt til at definere den—det omfatter brug af tegn-afgrænsere med identiske kategorikoder. Hvis afgrænserne i `` bruges til at kalde `\mymacro` er anderledes end dem, der blev brugt til at definere den (den “skabelon”, der er gemt i hukommelsen), kan TeX blive temmelig forvirret—når den forsøger at behandle `\mymacro` den, vil den ikke kunne matche den “skabelon”, den har gemt i sin hukommelse. Når TeX ser, at du kalder en makro, scanner den din inputtekst for at oprette nye tokens og prøver, token for token, at matche dem med tokenlisten `` skabelon, der er gemt som en del af din makros definition. Hvis de afgrænsere, der bruges i din inputtekst, resulterer i en række tokens, som ikke matcher dem, der er gemt i “skabelonen”, vil TeX normalt give en fejl. TeX er meget følsom—husk, at tegntokens er en kombination af tegnkode og kategorikode: hvis du ændrer kategorikoden for et tegn, får du en anden tokenværdi, der stammer fra det tegn. Antag, at vi ændrede kategorikoden for `z` til f.eks. 12—normalt er den 11—og forsøger at kalde vores makro sådan her: ```latex \catcode`z=12 \mymacro abc THIS TEXT defz more text here... ``` Denne gang vil det ikke virke, fordi kategorikoden for `z` er blevet ændret. Du vil se en fejl som denne: ```latex Løbsk argument? THIS TEXT defz ! Afsnittet sluttede, før \mymacro var færdig. \par l.22 ``` Når TeX læser og scanner `z` i `defz` den, kan den ikke genkende den som værende slutningen på `\mymacro`’s `` brugt i din inputfil. Indtil den ser denne fejlagtige `z` havde TeX korrekt matchet de første 3 tegn `def` men det `z` (med kategorikode 12) får TeX’s scanning til at snuble. Antag, at `z` havde en kategorikode på 11, da vi *definerede* `\mymacro`: det ville resultere i, at en tokenværdi på 256×11 + 122 = 2938 blev gemt som en del af `\mymacro`s definition (dvs. gemt som en del af “skabelonen”). Men med kategorikode 12, `z` vil nu skabe en tokenværdi på 256×12 + 122 = 3194. Fordi tokenværdien (for `z`) læst ind fra dit input (værdi 3194) ikke matcher den `z`-token, der findes i den gemte `` tokenlisteskabelon (værdi 2938), vil TeX fortsætte med at scanne dit input. TeX vil fortsætte med at scanne teksten, der følger efter din makro (*mere tekst her* ...) for at lede efter yderligere tokens—i et forsøg på at matche den gemte skabelon med de tokens, den finder i dit input. Den vil sandsynligvis ikke finde det korrekte tokenmønster, og der vil opstå fejl, når TeX “overskyder” dit input og fejlagtigt læser ekstra tekst for at oprette yderligere tokens—disse ekstra tokens burde ikke være blevet læst på dette tidspunkt og vil næsten helt sikkert give en fejl. Vi går mere i detaljer om dette i en fremtidig artikel. ## Andre anvendelser af tokenlister Andre kommandoer, der bruges til at oprette/gemme tokenlister, omfatter: ```latex \toks={...} \everypar={...} \everymath={...} \everydisplay={...} \everyhbox={...} \everyvbox={...} \output={...} \everyjob={...} \everycr={...} \errhelp={...} ``` Hver af disse kommandoer opretter en tokenliste ud fra tegnene og kommandoerne inden for klammerne ‘{...}’, og denne tokenliste er beregnet til at blive genbrugt under visse omstændigheder. For eksempel, `\everypar={...}` opretter og gemmer den et sæt tokens (en tokenliste), som TeX indsætter i inputtet lige før den starter et nyt afsnit. ## Skjulte anvendelser af tokenlister: eksempler I dette sidste afsnit vil vi se på nogle praktiske eksempler på tokenlister, der bruges på måder, du måske ikke forventer. ### Eksempel 1: \uppercase{...} og \lowercase{....}—midlertidige tokenlister Ud over eksplicitte kommandoer til at generere tokenlister er der omstændigheder, hvor TeX genererer en skjult og midlertidig intern tokenliste for at udføre særlig behandling. Husk, at når TeX læser/behandler dine inputtegn/kommandoer, bliver de omdannet til tokens: den grundlæggende byggesten, som TeX-motorer arbejder med. Et godt eksempel er kommandoerne `\uppercase{...}` eller `\lowercase{...}` fordi deres virkemåde ved første øjekast kan være temmelig forvirrende. Når du først forstår, hvad de gør—dybt inde i TeX og usynligt for brugeren—bliver deres funktion meget lettere at forstå. Antag, at du har en simpel række bogstaver, som du vil gøre store—f.eks. abcde og omdanne det til ABCDE. Det er ganske enkelt med TeX’s `\uppercase` kommandoen: ```latex \uppercase{abcde} ``` vil få TeX til at udskrive `ABCDE`. Antag nu, at vi vil gemme vores simple række bogstaver til senere brug—dvs. vi vil ikke udskrive dem med det samme, så vi bruger TeX’s eneste *interne* mekanisme—ikke en ekstern (fil-)mekanisme—til at gemme data: brug en tokenliste. Det kan vi gøre enten ved at oprette en makro eller ved at bruge en eksplicit tokenlistekommando: ```latex \toks100={abcde} \def\mychars{abcde} ``` Derefter kan du på et tidspunkt beslutte, at du gerne vil genbruge din række bogstaver, men denne gang i store bogstaver; så du prøver ```latex \uppercase{\the\toks100} ``` og ```latex \uppercase{\mychars} ``` Men ak, ingen af disse virker. Hvorfor ikke? ### Hemmelige tokenlister! For at forstå, hvordan kommandoerne `\uppercase{...}` `\lowercase{...}` faktisk virker, måtte jeg kigge ind i TeX’s indre mekanik, så følgende forklaring er baseret på det. Når TeX registrerer enten `\uppercase{}` eller `\lowercase{}` i dit input, er det første, TeX gør, at oprette en (midlertidig) intern tokenliste ud fra `` mellem de ‘{’ og ‘}’, som følger efter `\uppercase{...}` eller `\lowercase{...}` kommandoerne—den midlertidige tokenliste er intern i TeX. Et afgørende punkt, og centralt for at forstå, hvordan `\uppercase{}` og `\lowercase{}` faktisk virker, er, at eventuelle kommandoer eller makroer inde i `` ikke *ekspanderet*: alt, hvad TeX gør, er at generere tokens ud fra tegn og kommandoer placeret mellem `{...}`. Under udførelsen af `\uppercase{}` eller `\lowercase{}` udføres intet mellem klammerne: det bliver simpelthen omdannet til tokens. Efter `` inde i `{...}` er blevet omdannet til en (midlertidig) tokenliste, gennemgår TeX derefter hvert token i den liste igen og tester, om det er et *tegn* token eller et *kommandoen* token (ved at bruge tokenets numeriske værdi). Hvis TeX opdager et tegntoken, ændrer det tokenet for at justere bogstavets versalitet (afhængigt af om `\uppercase` eller `\lowercase` behandles). TeX ignorerer ganske enkelt alle kommandotokens og “kigger ikke ind” i nogen kommandotokens for at se, hvad de repræsenterer eller indeholder (f.eks. en makro, der indeholder tegn)—de springes blot over: kun tegntokens behandles faktisk/påvirkes af versalskifteoperationer. Så hvis vi for eksempel giver en TeX-kommando som `\uppercase{abcde}` vil TeX oprette en tokenliste ud fra `abcde` der kun indeholder tegntokens: de justeres alle for at skabe en række ændrede tokens, der repræsenterer A, B, C, D og E. Disse ændrede tokens sendes tilbage til TeX’s inputprocessor, hvilket resulterer i `ABCDE` at blive sat op. Men hvis vi har gemt vores tegn *i en makro*—for eksempel `\def\mychars{abcde}`—og forsøger at omdanne dem til store bogstaver sådan her: ```latex \uppercase{\mychars} ``` så vil det fejle, og abcde vil blive sat op—ikke ABCDE, som du måske forventer. Hvis vi så forsøger at gemme vores tegn i en tokenliste såsom `\toks0={abcde}` og gør `\uppercase{\the\toks0}` så vil det igen `\uppercase` fejle, fordi tokenlisten udelukkende vil bestå af tokens, som ikke påvirkes af `\uppercase`. Hvis vi tager eksemplet med vores makro, `\mychars`, efter at TeX registrerer `\uppercase` i inputtet, slår TeX betydningen op af `\uppercase` og udfører den, hvilket opretter en midlertidig tokenliste ud fra `{\mychars}`. Den midlertidige tokenliste indeholder tydeligvis kun ét token, som ikke er et tegntoken, men et token, der repræsenterer vores makrokommando `\mychars`: derfor, i forbindelse med udførelsen af `\uppercase`, ignoreres dette token—`\mychars` repræsenterer ikke et tegntoken. Men som nævnt ovenfor, når `\uppercase` har gjort sit arbejde, bliver den midlertidige tokenliste (oprettet ved handlingen af `\uppercase`) sendt tilbage til TeX’s fulde inputbehandlings- (scannings-) mekanisme. Når TeX genlæser den tokenliste, opdager den et token, der repræsenterer vores `\mychars` makro, som TeX udfører (ekspanderer) og genererer en række tegn til at sætte abcde—stadig med små bogstaver, fordi de var “pakket ind” i en makro og derfor usynlige for `\uppercase`. Når TeX har gennemgået den midlertidige tokenliste, der blev oprettet for `\uppercase{...}` eller `\lowercase{...}`, og har behandlet eventuelle tegntokens, skifter den derefter til at bruge den midlertidige tokenliste som sin inputkilde: den sætter tegn op (behandlede tegntokens) og udfører kommandoer og makroer. ### Hvordan kan dette løses? Fordi `\uppercase{...}` eller `\lowercase{...}` vil kun virke på tegntokens, har vi brug for en måde at “tvinge udpakkningen” af de tegn, der findes i vores makro `\mychars` (eller som findes i en `\toks` register) før `\uppercase{...}` eller `\lowercase{...}` virker på den. Med “udpakkning” mener vi egentlig TeX’s proces med *udvidelse*: * at erstatte en TeX/LaTeX-kommando med den *sekvens* af tokens *som den kommando* (*f.eks. en makro*) *består af,* eller * og derved producere den sekvens af tokens, som en kommando er designet til at *generere*. Et eksempel på en kommando, der genererer tokens, er `\jobname`, som producerer en sekvens af tegntokens, der repræsenterer navnet på den hoved-TeX-fil, der behandles. #### Mere lavniveau-magi: scantoks(..., ...) Her dykker vi virkelig ned i nogle mørkere hjørner af TeX’s indre virkemåde, så du kan ignorere dette afsnit, medmindre du kan lide detaljerne… Efter at TeX registrerer `\uppercase` eller `\lowercase` i inputstrømmen, udfører den en intern funktion kaldet `scantoks(..., ...)` hvis opgave det er at generere tokenlisten ved hjælp af elementerne mellem den åbne ‘{’ og den afsluttende ‘}’—som nævnt bliver tokenlisten derefter gennemgået for at opdage (og derefter justere) eventuelle tegntokens for at ændre bogstavernes versaler efter behov. Bemærk nøje, at vi her henviser til `scantoks(..., ...)` som den interne funktion, der er indbygget i TeX-motorernes kildekode—her henviser det ikke til navnet på en kontrolsekvens. Som en del af sit arbejde, `scantoks(..., ...)` kan den instrueres i, om den tokenliste, den konstruerer, skal ekspanderes eller ej, og for `\uppercase` og (`\lowercase`) ekspanderer den ikke tokens: den opretter dem blot og lægger dem i en tokenliste. En af de første ting, som `scantoks(..., ...)` skal gøre, er at tjekke for en åbnende ‘{’ (eller et hvilket som helst tegn med `\catcode` 1) fordi den skal sikre, at brugeren ikke har lavet en syntaksfejl og glemt den åbnende ‘{’ (eller et hvilket som helst tegn med kategorikode 1)—fordi et tegn med kategorikode 1 kræves for at afgrænse starten på en liste af elementer, der skal tokeniseres. Og her er tricket: opgaven med at lede efter en åbnende ‘{’ udløser `scantoks(..., ...)` at TeX’s ekspansionsproces køres, hvilket betyder, at følgende eksempler vil virke: ```latex \let\ob={ \uppercase\ob abcde} \def\obb{\ob} \uppercase\obb xyz} ``` Hvis vi tager eksemplet med `\obb`, en makro, genkendes den som en *ekspanderbar kommando* og ekspanderes behørigt af TeX (via `scantoks(..., ...)` funktionen) i sin søgen efter en åbningsklamme (ethvert tegn med kategorikode 1). Det betyder, at vi kan bruge “`\expandafter` trick” til at opnå vores mål om at “pakke” vores tegn ud af vores makros begrænsninger—dvs. ekspandere den. Bemærk, at `\expandafter` falder også ind under kategorien af at være en *ekspanderbar kommando*, så TeX udfører den her og lader den gøre sit arbejde som en del af jagten på en åbnende ‘{’ (eller et hvilket som helst tegn med kategorikode 1). Så hvis du definerer: ```latex \toks0={abcde} \def\mychars{abcde} ``` Og gør dette: ```latex \uppercase\expandafter{\mychars} \uppercase\expandafter{\the\toks0} ``` vil du i begge tilfælde nu se ABCDE sat op, fordi `\expandafter` medfører “udpakkning” (ekspansion) af `\mychars` og `\the\toks0`—begge resulterer i `\uppercase` at der ses en strøm af tegntokens, som de kan behandle for at ændre versalerne. ### Eksempel 2: \string—flere midlertidige tokenlister Internt klassificerer TeX `\string` Den `\string` kommandoen er designet til at konvertere et token til en menneskeligt læsbar tekstversion—dvs. sætte den menneskeligt læsbare tegnstreng, som dette token oprindeligt blev skabt af. For eksempel `\string\hello` opretter en midlertidig tokenliste, som indeholder tegnene \\, h, e, l, l, o — ja, selv inklusive det indledende ‘\’. Når først denne tokenliste er blevet oprettet, bliver den derefter genlæst af TeX, og teksten til kommandoen “`\hello`” sættes—ja, inklusive ‘\’, hvis du vælger den korrekte skrifttype… Du undrer dig måske over, hvordan/hvorfor TeX kan sætte escape-tegnet, når det normalt bruges til at få TeXs scanner til at oprette et kommandotoken: hvorfor gør den ikke det her? Svaret har med kategorikoder at gøre: normalt har et ‘\’-tegn catcode 0 (escape-tegn), men når `\string` genererer sin interne tokenliste, gør den noget lidt anderledes. Når den opretter en tegn-tokenliste, tildeler den kategorikode 12 til alle tegn bortset fra mellemrumstegnet, som tildeles catcode 10—husk, at tegntokens beregnes ud fra 256 x catcode + ASCII-værdi. Så når TeX genlæser (indlæser) den midlertidige tokenliste, som `\string` genereret fra `\hello`, TeX *ser den ikke et escape-tegn* fordi tokenet for ‘\’ blev beregnet med catcode 12 og ikke 0: TeX behandler blot ‘\’ som et almindeligt tegn og sætter det. Strengt taget bør vi nok bemærke, at TeX faktisk ikke genererer et token for escape-tegn, når den opdager dem i inputtet. Når den først har genkendt et tegn med kategorikode 0, bruges dette tegn blot til at “udløse” genereringen af et kontrolsekvenstoken: når det først har fået TeX til at gøre det, har escape-tegnet gjort sit arbejde og tages ikke længere i betragtning. ### Teknisk note En kommando kaldet `\showtokens{...}` (introduceret af e-TeX-motoren) kan vise tokenlister (i logfilen). Fra e-TeX-manualen: > Kommandoen `\showtokens{}` viser tokenlisten og gør det muligt at vise størrelser, som ikke kan vises af `\show` eller `\showthe`, f.eks.: > > ```latex > \showtokens\expandafter{\jobname} > ``` ## Afslutningsvis I afsnit 291 af TeX-kildekoden (se side 122 i [TeX: The Program](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373)) beskriver Knuth en tokenliste som følger: > “En tokenliste er en enkeltkædet liste af noder på ét ord i mem, hvor hvert ord indeholder et token og et link. Makrodefinitioner, outputrutinedefinitioner, markeringer, `\write` tekster og en del andre ting huskes af TeX i form af tokenlister, normalt forudgået af en node med en referenceoptælling i feltet “token\_ref\_count”.” Ved første læsning har dette måske ikke været let at forstå, men forhåbentlig giver det nu lidt mere mening. --- # 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/da/dybtgaende-artikler/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.