> 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/sv/fler-amnen/21-how-tex-macros-actually-work-part-3.md).
# Hur TeX-makron egentligen fungerar: Del 3
[Del 1](/latex/sv/fler-amnen/19-how-tex-macros-actually-work-part-1.md) [Del 2](/latex/sv/fler-amnen/20-how-tex-macros-actually-work-part-2.md) [Del 3](/latex/sv/fler-amnen/21-how-tex-macros-actually-work-part-3.md) [Del 4](/latex/sv/fler-amnen/22-how-tex-macros-actually-work-part-4.md) [Del 5](/latex/sv/fler-amnen/23-how-tex-macros-actually-work-part-5.md) [Del 6](/latex/sv/fler-amnen/24-how-tex-macros-actually-work-part-6.md)
## Dags att pausa!
Innan vi går vidare till nästa del av denna berättelse behöver vi göra en sammanfattning: påminna oss om vart vi är på väg och samla våra tankar för att se till att alla nyckelidéer finns på plats. Bara som en påminnelse bygger vårt genomgångsexempel på antagandet att TeX har läst en textrad som innehåller `Hej världen \\jobname` och att TeX sätter detta i sättning för att bygga upp ett stycke.
### Det yttersta målet
Vårt mål är att utveckla en bättre (djupare) förståelse av TeX-makroers natur och hur de fungerar. Men för att nå dit behöver vi först förstå hur TeX läser in en indatafil och bearbetar tecknen i den. Här är en sammanfattning av de ämnen som hittills har behandlats.
* TeX läser (skannar) varje tecken i din indata och för varje tecken har TeX två uppgifter med information:
* **teckenkod**: ett heltal som används för att identifiera det tecknet, t.ex. när det lagras i en .tex-indatafil;
* **kategorikod**: ett annat heltal, internt i TeX, som det använder för att tilldela varje tecken som läses från indata en betydelse.
* Så snart ett tecken har lästs in av TeX blir varje teckens kategori-kod *permanent* kopplad till just det enskilda tecknet genom skapandet av en teckentoken:
* TeX använder en enkel formel för att “packa ihop” en teckenkod och dess motsvarande kategori-kod till ett heltal som kallas en teckentoken.
* Du kan ändra betydelsen av vilket tecken som helst som TeX har *ännu inte läst in* genom att tilldela en annan kategori-kod till vilket tecken som helst vars beteende du vill ändra — dvs. ändra det sätt som TeX behandlar det tecknet på.
* Omdefiniering (omkartläggning) av kategori-koder görs med hjälp av TeX:s primitiv `\\catcode` kommandot.
* När TeX ser en kategori-kod på 0 går det över i ett särskilt skanningsläge och börjar leta efter ett kommando: antingen ett (eventuellt) flerbokstavligt *kontrollord* eller en enskild *kontrollsymbol*.
Hittills har vi tittat på TeX:s inläsnings- och skanningsprocess när den identifierar enskilda tecken och använder kategori-koden för varje tecken för att räkna ut vad som ska göras härnäst. Vissa tecken är bara vanliga textdelar för sättning (t.ex. kategori-kod 11), men vi har också sett blanktecken (kategori-kod 10) och escape-tecken (kategori-kod 0). Det finns andra kategori-koder som vi av korthetsskäl inte har tittat på — till exempel kategori-kod 1 (“börja grupp”, t.ex., `{`), kategori-kod 2 (“slut grupp”, t.ex., `}`) och andra. Varje kategori-kod spelar sin egen roll i TeX:s inläsningsskanning och den efterföljande bearbetningen av programvarans processer/algoritmer inne i TeX.
### Token: en snabb genomgång
Begreppet “tokens” är centralt för hur TeX fungerar: du kommer att se “tokens” nämnas eller refereras till genom hela TeX-relaterade böcker, artiklar och onlinegemenskaper, så det är värt att kort gå igenom detta ämne — du kan hitta mer detaljer i en tidigare publicerad artikel [Vad är en "TeX-token"?](/latex/sv/fordjupade-artiklar/53-what-is-a-tex-token.md)
Vi har redan sett att TeX omvandlar indatatecken till tokens genom att kombinera teckenkoden och kategori-koden till ett enda sammansatt heltal. TeX gör något liknande för kommandon: med hjälp av kommandots namn beräknar det ett heltal som kallas ett *kommandotoken* (vi kommer att utforska detta mer i detalj). Som vägledning kan du tänka på tokens som TeX:s metod för att “packa” de objekt det har läst från indata och göra dem redo att skickas vidare till nästa steg i TeX:s bearbetning. Att ha alla objekt (tecken eller kommandon) snyggt inbäddade i en enda numerisk representation gör det lättare att bearbeta dem längre fram i kedjan. När TeX till exempel vill lagra en del av din indata för att använda senare, såsom en makrodefinition, behöver TeX bara spara din makrodefinition, hur komplex den än är, som en följd av heltal, där varje heltal är en token som representerar ett tecken eller ett kommando som utgör en del av (ingår i) din makrodefinition.
## Så, vad händer nu?
I det sista avsnittet av Del 2 såg vi hur ett escape-tecken (kategori-kod 0) växlar TeX till ett särskilt bearbetningsläge där det letar efter namnet på ett kommando. I vårt exempel upptäckte TeX teckensträngen `jobname` och vi avslutade Del 2 vid den punkt där TeX skulle “göra något” med den teckensträngen (ett kommandonamn). I denna del ska vi i detalj titta på vad TeX gör härnäst.
När TeX har identifierat att en viss sekvens av tecken i din indatafil representerar namnet på ett kommando (här, `jobname`) kan TeX, beroende på vad det håller på med, behöva utföra det kommandot. Vi säger “kan behöva” eftersom det finns tillfällen då TeX inte omedelbart försöker utföra ett kommando: till exempel när det definierar ett makro (TeX bygger tokenlistor) — ämnen som vi kommer att diskutera senare. Vi fortsätter dock att följa vårt exempel där TeX sätter en paragraf i sättning och *kommer att*, i denna situation, behöver utföra `\jobname`.
### Från en teckensträng till att köra ett kommando: hur då?
Först återvänder vi till Grafik 5b från Del 2 där TeX har identifierat att en viss teckensträng i indata utgör namnet på ett kommando: `jobname`. Grafik 5b anger att TeX måste “Kontrollera interna tabeller...”. Vad betyder det *egentligen*?
En annan, mer detaljerad, beskrivning av hur TeX “kontrollerar interna tabeller” för att gå från att ha en teckensträng (t.ex. `jobname`) till att exakt ta reda på vad kommandot är och vad det betyder, finns i en tidigare artikel [Vad är en "TeX-token"?](/latex/sv/fordjupade-artiklar/53-what-is-a-tex-token.md) Här sammanfattar vi de viktigaste idéerna samtidigt som vi försöker undvika alltför mycket upprepning.
Låt oss börja med en analogi. Anta att du läser en bok och stöter på ett obekant ord: vad gör du? I dag är det nästan säkert att “ta fram Google”, men låt oss anta att du föredrar en äldre metod: du tar fram en ordbok som listar ord och ger deras betydelse(n). TeX har en motsvarande mekanism: en intern “ordbok” som listar alla kommandon som för närvarande är kända för TeX — och “betydelsen” av dessa kommandon. Med “betydelse” menar vi vilken typ av kommando det är: vad det gör, plus all annan information TeX kan behöva för att köra det kommandot. Notera också att termen “kommando” inkluderar alla TeX/LaTeX-makron som skrivits av användare/TeX-programmerare och de [hundratals inbyggda primitiva kommandon](/latex/sv/fler-amnen/46-tex-primitives-listed-by-tex-engine.md).
Om vi fortsätter med vår ordboksanalog. När vi som mänsklig läsare behöver slå upp betydelsen av ett ord söker vi i ordboken med hjälp av den alfabetiska ordlista som ordboken tillhandahåller — men så fungerar förstås inte TeX riktigt. Om vi återgår till vårt ursprungliga `jobname` exempel, hur hittar TeX i sin “ordbok” “betydelsen” av `jobname`— och vad ger egentligen den “betydelsen” TeX?
I stället för att tillhandahålla en intern “alfabetisk lista” över alla kommandon som TeX känner till gör det något lite annorlunda. TeX omvandlar hela teckenföljden — som finns i ett kommandonamn — till ett enda heltal, vilket kommer att användas för att identifiera (representera) det kommandot. Internt underhåller TeX en stor “ordbok” över alla kända kommandon i vilken det sparar/lagrar de *heltal* som beräknats från kommandonamn — notera att ordboken inte lagrar de faktiska kommandonamnen själva som sekvenser av bokstäver (kallade *strängar*). TeX använder den ordboken för alla sina inbyggda kommandon (primitiver) *och* den kommer att använda den för att lagra detaljer om alla makron (kommandon) som skapats av användare: namnet på ditt makro omvandlas till ett heltal och det heltalet “registreras” i TeX:s ordbok.
Varje gång TeX upptäcker ett kommando i din indata och behöver veta något om det kommandot, omvandlar det serien av tecken i kommandonamnet till ett “ekvivalent” heltal och använder det heltalet för att slå upp kommandot i sin “stora ordbok”. Programmerare bland er kanske vill veta att TeX använder en form av [hashfunktion](https://en.wikipedia.org/wiki/Hash_function) hashfunktion
### Grafik 6: Från tecken till kommandots betydelse
Följande grafik visar den resa som ett kommando genomgår när TeX omvandlar teckensträngen till ett ekvivalent heltal, vilket kallas **curcs**, och använder det heltalet för att slå upp kommandots betydelse i TeX:s “stora ordbok”. Resultatet av den uppslagningen är två informationsbitar: två heltal, kallade **curcmd** och **curchr**, som TeX kan använda för att räkna ut exakt vad kommandot gör och hur det därefter ska utföras.
Internt underhåller TeX en variabel som kallas **curcs** (**cur**rent **c**ontrol **s**sekvens) som används för att lagra heltalsvärdet för det kommando som TeX för närvarande arbetar med — dvs., **curcs** lagrar det heltal som beräknats från kommandots namn. Det är inte riktigt hela sanningen eftersom det finns en detalj till: om TeX just har läst/bearbetat ett tecken, inte ett kommando, sätter det **curcs** till värdet 0, för att komma ihåg att det senast inlästa var ett tecken, inte ett kommando.
### Vad kommandon betyder för TeX
Om vi tittar på mängden av [inbyggda kommandon som tillhandahålls av TeX-motorer](/latex/sv/fler-amnen/46-tex-primitives-listed-by-tex-engine.md) kan vi se att vissa av dessa kommandon är nära besläktade: de utför liknande uppgifter; till exempel finns det 4 primitiva kommandon som alla TeX-motorer använder för att definiera (skapa) makron: `\def`, `\gdef`, `\edef`, `\xdef`. Dessa 4 kommandon definierar alla makron men var och en gör det naturligtvis lite annorlunda. Om vi tänker på detta ur programmeringssynpunkt: här har vi 4 makrodefinitionskommandon som i stort sett gör samma sak, men vi behöver välja mellan dem för att passa deras individuella beteende.
För att hantera detta tilldelar TeX två värden till varje kommando och dessa två värden är vad TeX förstår som ett kommandos “betydelse” (dess roll/vad det gör) — dessa två värden är interna i TeX, djupt inne i programvaran, och en del av den “inre mekaniken” som inte är tillgänglig för användare. Varje TeX-kommando, vare sig det är ett inbyggt primitivt kommando eller ett användardefinierat kommando, tilldelas två värden som för TeX definierar/klassificerar dess beteende — vad det betyder för TeX. När TeX använder sin “stora ordbok” för att slå upp ett kommando hittar det dessa två viktiga informationsbitar:
* **kommandokod**: en sorts “allmän klassificering” som anger vilken “typ” av kommando det är — till exempel ett kommando för “makrodefinition” (ett av `\def`, `\gdef`, `\edef`, `\xdef`); ett kommando för “lådbildning” (ett av `\hbox`, `\vbox` eller `\vcenter`) och så vidare för de hundratals kommandon som TeX-motorer stöder. Makron (användardefinierade kommandon) tilldelas också en kommandokod.
* **kommandomodifierare**: Detta är kompletterande information som ger TeX specifik information om ett kommando. Makron (användardefinierade kommandon) tilldelas också en kommandomodifierare — även om kommandomodifieraren för makron spelar en något annan roll än för primitiver (för makron anger kommandomodifieraren var makrodefinitionen lagras i minnet).
Tillsammans identifierar kommandokoden och kommandomodifieraren varje kommando unikt. Här är kommandokoderna och kommandomodifierarna för makrodefinitionskommandona som de användes av Knuths ursprungliga TeX-programvara — notera att andra TeX-motorer kan använda andra värden men de följer exakt samma princip:
| | | |
| ------------ | -------------------------------------------------------- | ---------------------------------------------------------------- |
| **kommando** | kommando
kod
| kommando
modifierare
|
| `\def` | 97 | 0 |
| `\gdef` | 97 | 1 |
| `\edef` | 97 | 2 |
| `\xdef` | 97 | 3 |
### Sammanfattning: att förstå alla dessa variabler/värden
Vid det här laget översvämmas vi av massor av information om värden, variabler, kommandovärden och allehanda detaljer — det kan snabbt bli förvirrande så låt oss reda ut vad vi vet. När TeX läser något från din indata är det antingen ett tecken eller ett kommando. Varje gång TeX läser något från indata behöver det lagra information om vad det just har läst (skannat):
* För **tecken**: det behöver registrera teckenkoden och kategori-koden. Det behöver också skapa och lagra tokenvärdet som TeX beräknar med hjälp av dessa värden.
* För **kommandon**: TeX behöver känna till den numeriska motsvarigheten, **curcs**, som det beräknade från kommandonamnet. Det kan också behöva lagra den “betydelse” det hämtade genom att slå upp kommandot i TeX:s “ordbok”: kommandokoden och kommandomodifieraren. Utöver detta behöver TeX också beräkna ett tokenvärde som representerar detta kommando.
Ja, det är förvirrande: många variabler och tokenidéer svävar omkring, så låt oss försöka reda ut detta.
Internt använder TeX fyra globala variabler för att lagra information om det senaste objekt som TeX har läst in (eller för närvarande “arbetar med”) — vi kommer inte att diskutera dessa variabler i detalj, men att känna till deras existens hjälper till att ge lite mer bakgrund för att förstå vad som verkligen händer:
* **curcmd**: (aktuellt kommando) en heltalsvariabel. Den används för att lagra *det aktuella kommandot* värdet för det kommando som bearbetas *eller* den lagrar det aktuella *kategorikod* för det tecken som bearbetas;
* **curchr**: (aktuellt tecken) en heltalsvariabel, men vad den lagrar beror på vad TeX just har läst från sin indata:
* **tecknet**: Om det senast inlästa objektet är ett tecken, **curchr** lagrar det aktuella *teckenkod*.
* **kommandot**: Om det senast inlästa objektet är ett kommando, **curchr** lagrar det *kommandomodifierare*: tilläggsinformation som TeX använder för att stödja/klargöra **curcmd**— eftersom, som vi såg ovan, vissa kommandon delar samma värde av **curcmd**
* **curcs**: (aktuellt kontrollsekvens) en heltalsvariabel som lagrar värdet som beräknats från teckenföljden i ett kommandonamn. **curcs** = 0 om det senast lästa objektet var ett enskilt tecken och inte namnet på en kontrollsekvens (ett kommandonamn);
* **curtok**: (aktuellt token) en heltalsvariabel som innehåller värdet för den aktuella tokenen — vilket antingen är en kommandotoken eller en teckentoken.
Här visas informationen ovan i tabellform:
| | | |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Global variabel som används inuti TeX:** | **När TeX skannar ett tecken:** | **När TeX skannar ett kommando:** |
| **curcmd** | Lagrar kategori-koden för det aktuella tecknet | Lagrar *kommandokod*— som identifierar den aktuella kommandotypen |
| **curchr** | Lagrar teckenkoden för det aktuella tecknet | Lagrar tilläggsdata (kallad *kommandomodifierare*) som ger ytterligare information om det aktuella kommandot |
| **curcs** | 0 | Ett icke-noll positivt heltal som beräknas (via en hashfunktion) med hjälp av teckenföljden som finns i kommandonamnet. Det används för att komma åt TeX:s “ordbok” för att slå upp det aktuella kommandots betydelse — för att hämta dess kommandokod och kommandomodifierare. |
| **curtok** | För 8-bitars TeX-motorer beräknas en *teckentoken* med formeln: $$\text{curtok}=256\times \text{curcmd} + \text{curchr}$$ där $$\text{curcmd}$$ är tecknets kategori-kod och $$\text{curchr}$$ är teckenkoden | För 8-bitars TeX-motorer beräknas en *kommandotoken* med formeln: $$\text{curtok}=4095 + \text{curcs}$$ |
### Ytterligare noteringar om den aktuella tokenen
För tecken erhålls det maximala möjliga tokenvärdet med den största kategori-koden (15) och den största teckenkoden som för 8-bitars TeX-motorer är 255. I teorin (för 8-bitars TeX-motorer) är det maximala teckentokenvärdet, $$\text{curtok}\_{\text{max}}$$, är:
$$\text{curtok}\_{\text{max}}= 256\times 15 + 255 = 4095$$
Vi säger “i teorin” eftersom kategori-kod 15 används för att representera ett “ogiltigt tecken” som får TeX att generera ett fel: ett ogiltigt tecken kommer aldrig att ta sig igenom TeX:s skanningsprocess och blir därför aldrig en teckentoken.
För kommandon är den aktuella tokenen ($$\text{curtok}$$) beräknad från $$\text{curtok}=4095 + \text{curcs}$$ men för kommandon $$\text{curcs}$$ är *alltid* icke-noll, och TeX kan därför enkelt avgöra vad en token representerar:
* Om $$\text{curtok} > 4095$$ då är det en kommandotoken;
* Om $$\text{curtok} < 4095$$ det är en teckentoken.
I praktiken använder TeX tokens, ett enkelt heltalsvärde, för att “packa” all information det behöver veta om ett objekt som lästs från indata.
## Del 4
I Del 4 utforskar vi en rad exempelmakron för att demonstrera rollen och syftet med ett makros `` avsnitt som fungerar som en “tokenmall” som kan konstrueras genom användning av avgränsartokens.
[Del 1](/latex/sv/fler-amnen/19-how-tex-macros-actually-work-part-1.md) [Del 2](/latex/sv/fler-amnen/20-how-tex-macros-actually-work-part-2.md) [Del 3](/latex/sv/fler-amnen/21-how-tex-macros-actually-work-part-3.md) [Del 4](/latex/sv/fler-amnen/22-how-tex-macros-actually-work-part-4.md) [Del 5](/latex/sv/fler-amnen/23-how-tex-macros-actually-work-part-5.md) [Del 6](/latex/sv/fler-amnen/24-how-tex-macros-actually-work-part-6.md)
---
# 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/sv/fler-amnen/21-how-tex-macros-actually-work-part-3.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.