> 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/18-how-overleaf-created-the-tex-primitive-reference-data.md). # Hur Overleaf skapade referensdatan för TeX-primitiver Denna artikel beskriver de metoder och tekniker som användes för att ta fram de två korsreferenstabellerna över TeX:s primitiva kommandon: * [TeX-primitiver listade per TeX-motor](/latex/sv/fler-amnen/46-tex-primitives-listed-by-tex-engine.md) och; * [TeX-primitiver listade per CJK-TeX-motor](/latex/sv/fler-amnen/45-tex-primitives-listed-by-cjk-tex-engine.md). Denna information ges för läsare som är intresserade av de finare detaljerna, men är inte ett krav för att använda själva korsreferenstabellen. För att tillgodose olika läsares behov ger vi en mycket kort sammanfattning tillsammans med en längre förklaring för dem som vill fördjupa sig i frågorna. ## Kort sammanfattning/översikt För att bygga korsreferenstabellen bearbetade Overleaf källkoden för 9 TeX-motorer för att extrahera listan över primitiver som stöds av var och en: den processen producerade 9 textfiler (1 fil per TeX-motor). Dessa 9 uppsättningar primitiver kombinerades för att skapa en ”huvudlista” som i praktiken var en förening av de enskilda uppsättningarna primitiver: vilket gav totalt omkring 1000 unika primitiver spridda över de olika motorerna. För varje motor korsrefererades dess egen lista över primitiver mot huvudfilen (uppsättningen av alla kommandon) för att avgöra vilka av dessa \~1000 kommandon den stödde: dessa jämförelser tabelleras i följande två tabeller: * [Korsreferensdata för TeX-primitiver](/latex/sv/fler-amnen/46-tex-primitives-listed-by-tex-engine.md) * [Korsreferensdata för TeX-primitiver (för CJK-motorer)](/latex/sv/fler-amnen/45-tex-primitives-listed-by-cjk-tex-engine.md) ## ”Bygga programvara” 101: Vad betyder det? Genom resten av denna artikel hänvisar vi till begreppet att ”bygga TeX-motorer”, vilket kan vara ett obekant koncept om du inte är programmerare, eller inte programmerar i kompilerade språk som C eller C++. För våra ändamål är att bygga programvara—dvs. TeX-motorer—processen att skapa ett körbart TeX-program från dess beståndsdelar—källkodsfilerna skrivna i det programmeringsspråk som används för att utveckla programmet. ## Full version: Vill du ha detaljerna? Läs vidare... Varje TeX-baserad sättningsmotor stöder en ”dialekt” av TeX-språket: en viss uppsättning primitiva kommandon som styr varje motors sättningsfunktioner och utgör byggstenarna för att skapa/definiera makron: användardefinierade sekvenser av kommandon. Varje makro, oavsett om det är skrivet för LaTeX, plain TeX eller något annat makropaket, är i slutändan uppbyggt av primitiva kommandon—även om du kan behöva gräva dig ganska långt ner genom lager av ytterligare makron innan du når TeX-primitivernas ”berggrundslager”. De 9 TeX-motorer som analyserades för att ta fram referensdata för primitiva kommandon har naturligtvis många kommandon gemensamma, men varje TeX-motor har också sina egna primitiva kommandon, tillagda av dess utvecklare, för att ge stöd för de funktioner som är specifika för den ”versionen” av TeX. En TeX-motors primitiva kommandon är inbyggda i den körbara TeX-programvaran: primitiver är inte makron som konstrueras av användare, de är fundamentala, odelbara/atomära instruktioner som används för att styra varje motors sättningsbeteende. Följaktligen är det mest tillförlitliga sättet att skapa en definitiv lista över primitiva kommandon som stöds av vilken TeX-motor som helst att granska den faktiska källkod från vilken de körbara TeX-programmen byggs (kompileras) och extrahera listan över primitiver som definieras i källkoden. Låter som att det borde vara enkelt, eller hur? Men på grund av TeX:s 40-åriga utvecklingshistoria är det inte särskilt okomplicerat att utforska/granska källkodsfilerna för TeX-motorer (utom LuaTeX). Orsaken till dessa komplexiteter ligger i de verktyg, det programmeringsspråk (Pascal) och den metodik (litterär programmering) som Knuth använde för att skriva den ursprungliga TeX-källkoden—från vilken alla andra motorer i slutändan härstammar. Vi noterar ett undantag för LuaTeX eftersom dess kärnmodulkod skrevs om i C för att ta bort användningen av Pascal och andra äldre komplexiteter som beskrivs nedan (Web2C); följaktligen, även om LuaTeX:s källkod är omfattande, är sättet den är ”paketerad” och distribuerad på mycket mer begripligt jämfört med andra TeX-motorer. Som följd av detta, och baserat på de arbetsflöden/processer som används för att bygga dem från källkod, är det praktiskt att gruppera TeX-motorer i två kategorier: 1. LuaTeX: anpassad (modernare) byggprocess 2. Alla andra motorer: äldre (Web2C) byggprocess ## Det äldre kodarvets sammanhang: Varför det är komplicerat att bygga (de flesta) TeX-motorer Som vi kommer att utforska nedan släppte Knuth sin ursprungliga TeX-källkod som en enda, monolitisk fil kallad `tex.web` som Knuth fortsätter att uppdatera vart sjunde år för att rätta eventuella återstående buggar—inga nya funktioner läggs någonsin till, det är enbart en buggfixningsinsats. Källkodens filändelse för TeX (`.web`) är osannolikt bekant och du kanske undrar vilket språk Knuth använde för att skriva TeX? Svaret är Pascal men `.web` ändelsen behöver lite mer förklaring. Knuth utvecklade en programmeringsmetod som han kallade [litterär programmering](https://en.wikipedia.org/wiki/Literate_programming) där ett programs källkod och dokumentation kombineras och ges ut som en enda sammansatt fil (kod plus dokumentation) med ändelsen `.web`: den filtypen kallas en WEB-fil. Vi förklarar WEB-filer lite mer i detalj nedan. ### Att skapa nya TeX-motorer: Knuths villkor Även om Knuth sedan länge har gjort sin TeX-källkod (`tex.web`) fritt tillgänglig för alla, gjorde han, vilket är hans fulla rätt, ett viktigt villkor att hans (`tex.web`) källkod inte får redigeras/ändras direkt och distribueras på nytt med programnamnet ”TeX”. I källkoden skriver han: ``` % Detta program är upphovsrättsskyddat (C) 1982 av D. E. Knuth; alla rättigheter förbehålls. % Kopiering av denna fil är endast tillåten om (1) du är D. E. Knuth, eller om % (2) du inte gör några som helst ändringar i din kopia. (WEB-systemet tillhandahåller % för ändringar via en hjälpf fil; huvudfilen ska förbli intakt.) ``` och även: ``` Om detta program ändras bör det resulterande systemet inte kallas `\TeX'; det officiella namnet `\TeX' i sig är reserverat för mjukvarusystem som är fullt kompatibla med varandra. En särskild testsvit kallad ``\.{TRIP} test'' finns tillgänglig för att hjälpa till att avgöra om en viss implementation förtjänar att kallas `\TeX' [jfr.~Stanford Computer Science report CS1027, november 1984]. ``` I praktiken: gör inte ändringar genom att redigera och distribuera modifierade versioner av den huvudsakliga TeX-källkoden och fortsätt kalla den `tex.web`. Om du verkligen vill göra ändringar, t.ex. lägga till nya primitiver osv., måste du göra dessa ändringar genom att använda ”ändringar via en hjälpf il” och ge ditt ”derivat av TeX”-program ett namn som skiljer det från ”TeX”, vilket i sättningsform ($$\mathrm\TeX$$) är ett varumärke som tillhör American Mathematical Society. ### Arvet av det äldre Även om det har funnits försök att helt skriva om TeX med moderna programmeringsspråk och metoder—såsom de två Java-baserade initiativen [New Typesetting System](https://en.wikipedia.org/wiki/New_Typesetting_System) och [εχTEX](http://www.extex.org/) och andra såsom [ett i Clojure](https://www.infoq.com/news/2015/01/implementing-tex-in-clojure), har inget varit helt framgångsrikt. Historien om projekt och initiativ som utformats för att vidareutveckla TeX är ett intressant ämne och läsare kanske vill [besöka UK TeX FAQ](https://texfaq.org/FAQ-enginedev) för mer information. De icke-LuaTeX-initiativ som också har varit framgångsrika, såsom e-TeX, pdfTeX, XeTeX och andra motorer, har byggt *direkt ovanpå* Knuths ursprungliga kod: de tar hans källkod och ”tillämpar ändringar” för att härleda en ny motor med ytterligare funktioner—såsom att lägga till nya primitiver, producera PDF-utdata, stödja textinmatning i UTF-8 och så vidare. Även om den vägen har lett till anmärkningsvärda framgångar innebär det också att dessa derivata motorer ärver den äldre kod och de utvecklingstekniker som Knuth skapade för 40 år sedan. Det viktiga här är att, bortsett från LuaTeX, skapas de flesta TeX-motorer som härstammar från Knuths ursprungliga källkod genom att ta en enda monolitisk fil (vanligen `tex.web`) och tillämpa ändringar som genererar ännu en enda monolitisk fil som innehåller den nya motorns kärnkällkod. Avancerade läsare kanske vill hoppa fram till de kvalificerande [anmärkningarna om pdfTeX och XeTeX](#aside-xetex-and-pdftex). ### Lite ytterligare TeX-historia/bakgrund TeX:s ögonblick av tillkomst var [noterat i Knuths dagbok som den 30 mars 1977](/latex/sv/fordjupade-artiklar/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md#the-genesis-of-tex-a-brief-history), nu mer än 40 år sedan. Internt är TeX ett oerhört komplext program vars källkod Knuth lade stor möda på att [dokumentera i exceptionell detalj](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373). För att göra det utvecklade Knuth en programmeringsstil som han kallade [litterär programmering](https://en.wikipedia.org/wiki/Literate_programming) där ett programs källkod och dokumentation kombineras och ges ut som en sammansatt fil med ändelsen `.web` (kallad en WEB-fil). Knuth valde Pascal som programmeringsspråk för att skriva sin TeX-programvara och använde, inte överraskande, TeX:s sättningsspråk för att skriva den slutliga dokumentationen. Följaktligen publiceras Knuths TeX:s huvudkällkod som en enda, monolitisk fil kallad `tex.web`: en blandning av Pascal-källkod och TeX-sättningskod för dokumentationen. Om ett program skrivs med Knuths litterära programmeringsstil/metodik (liksom TeX, MetaFont, BibTeX och andra) behöver du förbehandla WEB-filen för att extrahera dokumentationen eller källkoden. För att komma åt programmets dokumentation bearbetar du WEB-filen (t.ex. `tex.web`) med ett verktyg kallat [WEAVE](http://tug.org/texinfohtml/web2c.html#weave-invocation) som producerar dokumentationen som en `.tex` fil som du kan sätta. För att extrahera källkoden i Pascal använder du ett annat verktyg kallat [TANGLE](http://tug.org/texinfohtml/web2c.html#tangle-invocation) som matar ut en fil med ändelsen `.p` som innehåller Pascal-källkod. Vid tiden för skrivandet (början av 2019) är den senaste versionen av Knuths TeX 3.14159265, daterad januari 2014. Återigen, notera att Knuths TeX-källkod ryms i bara en enda fil som innehåller omkring 25 000 rader TeX/Pascal-kod! ### Från Pascal till C Under de 40+ år som förflutit sedan TeX:s tillkomst föll Pascal ur modet och i dag är det få, om några?, som ens överväger att bygga TeX från dess ursprungliga Pascal-källkod. För att kringgå Knuths användning av Pascal utformades ett arbetsflöde kallat [Web2C](http://tug.org/texinfohtml/web2c.html) cirka 1987) där TeX:s Pascal-källkod mekaniskt (dvs. via programvara) konverteras till sin motsvarighet i C-kod, som sedan används för att kompilera TeX och bygga det körbara programmet. Det fungerar bra men den enda nackdelen är att den mekaniskt genererade C-källkoden inte är avsedd för en lös människas granskning: den är *extremt* ordrik och nästan ogenomtränglig, eftersom den är avsedd för kompilatorer, inte människor—här är en skärmbild som visar ett litet fragment av C-koden som genererats från TeX:s Pascal-källkod: ![](/files/11406992c2ca4f2407869d379af7528f0d24b010) ### En annan Knuth-ism: WEB-ändringsfiler Som nämnts ovan, för att bygga vidare på Knuths ursprungliga källkod ”tillämpar du ändringar” eller, med Knuths ord, gör ”ändringar via en hjälpf il”: men vad betyder detta egentligen? Här kommer *mekanismen för ändringsfiler*. ### Ändringsfiler: mekanismen för att skapa nya TeX-motorer Utvecklare som vill utöka Knuths TeX på något sätt, dvs. bygga vidare på Knuths ursprungliga arbete, vill vanligtvis skapa en helt ny ”version” av TeX eller tillhandahålla en *utökning* som kan läggas till i vilken TeX-motor som helst. Exempel på utökningar är [SyncTeX](https://github.com/jlaurens/synctex) och [EncTeX](https://ctan.org/pkg/enctex?lang=en)—SyncTeX är till exempel en mycket användbar utökning som nu ingår i alla TeX-motorer. Behovet av EncTeX har till stor del överflödiggjorts av utvecklingen av Unicode-medvetna TeX-motorer—men notera att EncTeX är inbyggt i pdfTeX. Oavsett om önskemålet är att producera en ny ”version” av TeX (dvs. en avledning av Knuths ursprungliga TeX) eller att skapa en utökning, börjar dess utvecklare med Knuths ursprungliga källkod och tillämpar de ändringar som behövs för att skapa en ny TeX-motor (eller en tilläggsutökning). Men som nämnts ovan måste alla som vill ändra TeX:s beteende göra det med hjälp av ”ändringar via en hjälpf il” eftersom dessa ändringar/modifieringar inte får göras genom *direkt* redigering av Knuths ursprungliga källkod: utvecklare måste använda den så kallade WEB *mekanismen för ändringsfiler*. Koden för att modifiera Knuths TeX skrivs i WEB-”språket” och sparas i en eller flera kodfiler (kallade *ändringsfiler*) som därefter *slås samman* med Knuths ursprungliga, orörda, huvudkällkod. Den sammanslagningsprocessen skapar en ny sammansatt WEB-fil som nu innehåller den *kärn-* källkod som den nya/modifierade TeX-baserade programvaran består av. *Ändringsfiler* har ofta ändelsen `.ch` men i praktiken kan de ha vilken ändelse som utvecklarna önskar. #### Hur använder/tillämpar man ändringsfiler? Numera är det enklaste sättet att tillämpa ändringsfiler och modifiera en ”huvud”-WEB-fil med ett hjälpprogram kallat [TIE](https://ctan.org/pkg/tie). Om du till exempel ville modifiera Knuths TeX genom att lägga till, säg, ett par nya primitiver eller om du ville ändra beteendet hos en befintlig (standard) TeX-primitive, skulle du skriva din kod (i Pascal!) med WEB-systemet för litterär programmering och spara den i en fil som till exempel `myprim.ch`. Nästa steg är att slå samman din kod (i `myprim.ch`) med Knuths huvudkällkod `tex.web` och skapa en ny, sammansatt, WEB-fil som representerar vad vi ska kalla `mytex.web`. För att göra detta kör du helt enkelt TIE-programmet så här: ``` tie -m mytex.web tex.web myprim.ch ``` Om sammanslagningen lyckas kommer detta att resultera i en ny WEB-fil, `mytex.web`och lämnar Knuths huvudkällkod `tex.web` helt oförändrad, som krävs. Anta nu att någon annan gillar de ändringar du gjorde och vill modifiera ditt arbete för att lägga till sina ändringar ovanpå, eller utöver, det du har gjort. I stället för att distribuera din modifierade version av TeX (`mytex.web`) bestämmer du dig för att endast publicera/dela ändringsfilen, `myprim.ch`. Den som vill bygga vidare på ditt arbete kan nu skapa och dela sin egen ändringsfil som till exempel heter `moreprim.ch` som på något sätt utökar din kod. Alla andra som vill dra nytta av båda ändringsfilerna kan nu generera en ny sammansatt WEB-fil genom att slå samman *båda* ändringsfilerna med Knuths ursprungliga för att generera ännu ett TeX-program som till exempel kallas `newmytex.web`: ``` tie -m newmytex.web tex.web myprim.ch moreprim.ch ``` ### Verkliga TeX-system: flera ändringsfiler Ovanstående beskrivning av TIE ligger faktiskt mycket nära det sätt på vilket många TeX-motorer byggs i praktiken: de börjar med Knuths `tex.web` och lägger till en följd av ändringsfiler för att generera WEB-källfilen för den motorn. Varje TeX-motor kräver sin egen särskilda uppsättning ändringsfiler, som måste tillämpas/bearbetas (slås samman) i strikt ordning: får du ordningen fel kommer sammanslagningsprocessen att misslyckas eftersom varje ändringsfil i en sekvens förlitar sig på ändringar som införts av ändringsfiler tidigare i kedjan. Här är en exempelkörning av TIE som tillämpar flera ändringsfiler på Knuths `tex.web` för att generera `ktex.web`—den sammansatta WEB-filen med ändringar av Knuths TeX som gör den redo (lämplig) för konvertering till C via Web2C-processen. Notera också följande: * `tex.ch` är en mycket stor ändringsfil som bland annat modifierar TeX så att det använder Kpathsea; * SyncTeX-utökningen läggs till via flera ändringsfiler. ``` tie -m ktex.web tex.web tex.ch enctex.ch synctex-def.ch0 synctex-mem.ch0 synctex-mem.ch2 synctex-rec.ch0 synctex-rec.ch1 synctex-rec.ch2 tex-binpool.ch Detta är TIE, CWEB-version 2.4. Copyright (c) 1989,1992 av THD/ITI. Alla rättigheter förbehålls. (tex.web) (tex.ch) (enctex.ch) (synctex-def.ch0) (synctex-mem.ch0) (synctex-mem.ch2) (synctex-rec.ch0) (synctex-rec.ch1) (synctex-rec.ch2) (tex-binpool.ch) ....500....1000....1500....2000....2500....3000....3500....4000....4500 ....5000....5500....6000....6500....7000....7500....8000....8500....9000 ....9500....10000....10500....11000....11500....12000....12500....13000 ....13500....14000....14500....15000....15500....16000....16500....17000 ....17500....18000....18500....19000....19500....20000....20500....21000 ....21500....22000....22500....23000....23500....24000....24500.... (Inga fel hittades.) ``` #### Sidospår: XeTeX och pdfTeX För fullständighetens skull bör vi notera att byggprocessen för pdfTeX och XeTeX faktiskt inte börjar med Knuths `tex.web`; i stället börjar de med filer som heter `pdftex.web` och `xetex.web` respektive: sannolikt för att ändringarna är så omfattande att det är mer meningsfullt att dela/publicera WEB-filer som redan innehåller de mycket betydande ändringarna av Knuths ursprungliga kod. ### Ett exempel: e-upTeX Det japanska TeX-samfundet har utvecklat ett antal TeX-motorer utformade för att hantera komplexiteten i sättning av japansk text: * **pTeX**: Knuths TeX-motor utökad för att stödja japansk sättning; * **e-pTeX**: En kombination av e-TeX och pTeX (plus några primitiver som introducerats av pdfTeX); * **upTeX**: En Unicode-medveten version av pTeX plus utökningar för bättre hantering av CJK (kinesiska, japanska och koreanska); * **e-upTeX**: En kombination (sammanfogning) av e-TeX och upTeX. #### Generering av den sammansatta källfilen för e-upTeX För att skapa den sammansatta WEB-källfilen för e-upTeX (med SyncTeX) börjar du med Knuths `tex.web` men behöver tillämpa **26** enskilda ändringsfiler, i följande ordning, för att få fram en enda sammansatt fil från vilken listan över primitiva kommandon kan extraheras: ``` etex.ch, tex.ch0, tex.ch, tex.ech, etex.ch0, ptex-base.ch, uptex-m.ch, euptex.ch0, eptex.ech, etex.ch1, euptex.ch1, synctex-def.ch0, synctex-ep-mem.ch0, synctex-mem.ch0, synctex-e-mem.ch0, synctex-ep-mem.ch1, synctex-p-rec.ch0, synctex-rec.ch0, synctex-rec.ch1, synctex-e-rec.ch0, synctex-p-rec.ch1, fam256.ch, pdfstrcmp-eup-pre.ch, pdfutils.ch, pdfstrcmp-eup-post.ch, tex-binpool.ch ``` #### Tillämpa ändringsfiler: vilka filer och i vilken ordning? Som nämnts är det oerhört viktigt att tillämpa/bearbeta ändringsfiler i strikt ordning—men hur får man reda på vilka filer som behövs och i vilken ordning de ska bearbetas? Lyckligtvis finns den avgörande informationen dokumenterad i filer som ingår i TeX Live-distributionen, och en genomgång av TeX Lives källkod avslöjade de regler som styr byggkraven för varje TeX-motor. Genom att följa dessa regler kunde Overleaf återskapa den sammansatta WEB-källkodsfiler för varje TeX-motor och extrahera en lista över primitiver för vidare databehandling. ## Och till sist: Hur extraherar man listan över primitiver? När den sammansatta WEB-filen har konstruerats är uppgiften att extrahera listan över primitiver, med hjälp av reguljära uttryck, enkel eftersom alla primitiva kommandon definieras (”registreras”) med en enda Pascal-funktion som kallas `primitive(...)`. Här är några verkliga exempel tagna från Knuths `tex.web` källkod: ``` primitive("lineskip",assign_glue,glue_base+line_skip_code) primitive("baselineskip",assign_glue,glue_base+baseline_skip_code) primitive("parskip",assign_glue,glue_base+par_skip_code) primitive("abovedisplayskip",assign_glue,glue_base+above_display_skip_code) primitive("belowdisplayskip",assign_glue,glue_base+below_display_skip_code) primitive("abovedisplayshortskip",assign_glue,glue_base+above_display_short_skip_code) ... ... ``` Som du kan se är `primitive(...)` funktionen mycket väl lämpad för textbearbetning med reguljära uttryck: namnet på den primitive som registreras står inom citattecken (`"..."`) tillsammans med ytterligare data som klassificerar beteendet hos varje primitive (det kommer vi inte att gå in på i detalj). Efter att listan över primitiver för varje motor extraherats bearbetades dessa data av några Lua-skript för att generera HTML som innehåller de tabellerade resultaten. ### Tillbaka till LuaTeX Vi har noterat att LuaTeX inte använder exakt samma byggprocesser som de andra 8 TeX-motorerna. Efter att kort ha utforskat Web2C-processen, konverteringen från Pascal till C och mekanismen med ändringsfiler kan vi nu förklara var LuaTeX skiljer sig: utvecklarna av LuaTeX beslutade att avstå från den omständliga processen att konvertera Pascal till C—som noteras i [LuaTeX Reference Manual](http://www.pragma-ade.com/general/manuals/luatex): > ...kompileringsramverket är web2c och vi fortsätter att använda det men utan steget från Pascal till C. Kärnmotorn i LuaTeX skrevs om i C, vilket innebär att dess byggprocess är något mer standardiserad och definitivt mycket bekvämare. En användbar följd är att primitiver som stöds av LuaTeX är snyggt utbrutna i en separat C-källkodfil, vilket avsevärt underlättade uppgiften att komma åt/lista dem. Strängt taget bör vi också notera att vissa av LuaTeX:s källkodsfiler använder en variant av Knuths litterära programmeringsmetodik, kallad [CWEB](https://en.wikipedia.org/wiki/CWEB), som bygger på C och inte Pascal. ### Inte bara WEB-filer: annan källkod krävs Efter att den sammansatta WEB-källfilen har genererats för vilken TeX-motor som helst (utom LuaTeX) måste Pascal-källkoden extraheras och konverteras till C-kod, men det är inte hela lösningen. Utöver C-koden som genereras från WEB-källan (Pascal⮕C) förlitar sig de flesta TeX-motorer också på (kräver) ett antal ytterligare hjälpkällkodsfiler (bibliotek) som vanligtvis skrivs i C—såsom [Kpathsea](https://www.tug.org/kpathsea/). Hjälpkällfiler (bibliotek) implementerar funktioner som inte behöver, eller inte kan, skrivas i WEB (Pascal). Allt som skrivs i WEB-”språket” för TeX måste använda Pascal-språket, som därefter extraheras och konverteras till maskinproducerad C: om du ändå inte behöver göra det, varför inte bara skriva det i C eller C++ från början. --- # 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/18-how-overleaf-created-the-tex-primitive-reference-data.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.