> 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/pl/artykuly-szczegolowe/21-how-does-expandafter-work-tex-uses-temporary-token-lists.md).

# Jak działa \expandafter: TeX używa tymczasowych list tokenów

[Część 1](/latex/pl/artykuly-szczegolowe/19-how-does-expandafter-work-an-introduction-to-tex-tokens.md) [Część 2](/latex/pl/artykuly-szczegolowe/22-how-does-expandafter-work-the-meaning-of-expansion.md) [Część 3](/latex/pl/artykuly-szczegolowe/21-how-does-expandafter-work-tex-uses-temporary-token-lists.md) [Część 4](/latex/pl/artykuly-szczegolowe/20-how-does-expandafter-work-from-basic-principles-to-exploring-tex-s-source-code.md) [Część 5](/latex/pl/artykuly-szczegolowe/17-how-does-expandafter-work-a-detailed-macro-case-study.md) [Część 6](/latex/pl/artykuly-szczegolowe/18-how-does-expandafter-work-a-detailed-study-of-consecutive-expandafter-commands.md)

## Rozszerzanie i wewnętrzne listy tokenów

Jak dotąd zbadaliśmy tokeny, listy tokenów i podstawowe zasady stojące za koncepcją rozszerzania w TeX-u. W tej sekcji użyjemy prymitywu TeX-a `\jobname` aby wprowadzić ważny aspekt przetwarzania rozszerzeń: użycie przez TeX *tymczasowych list tokenów*—które są *fundamentalnym* aspektem tego, jak `\expandafter` działa, jak zobaczymy później w tej serii artykułów.

`\jobname` jest rozszerzalnym prymitywem TeX-a, którego rozwinięcie generuje serię tokenów znakowych reprezentujących nazwę głównego pliku `.tex` wejściowego. Na przykład załóżmy, że mielibyśmy następujący tekst jako część `.tex` plik o nazwie `mycode.tex`:

```
    Nazwa mojego pliku to \jobname .tex %Uwaga: spacja po \jobname
```

Dałoby to skład

```
    Nazwa mojego pliku to mycode.tex
```

Gdy używamy `\jobname` polecenia, wynikowe znaki składu nie są odczytywane z Twojego fizycznego `.tex` pliku, więc skąd pochodzą: gdzie TeX przechowuje/czyta te tokeny? Niewidoczne dla użytkownika (tj. głęboko wewnątrz samego TeX-a) proces rozwijania dla `\jobname` tworzy tymczasową listę tokenów zbudowaną z serii tokenów znakowych reprezentujących nazwę Twojego pliku. Gdy tylko `\jobname` utworzy tę listę tokenów, TeX tymczasowo „odwraca wzrok” od bieżącego źródła wejścia (tutaj, naszego `.tex` pliku), aby odczytywać tokeny (tokeny znakowe) z tej tymczasowej listy tokenów. Gdy TeX potrzebuje kolejnego tokenu wejściowego, odczyta następny token z tej wewnętrznej listy i będzie to robił aż do końca listy; w tym momencie TeX wznawia odczyt tokenów z poprzedniego źródła wejścia, którym tutaj byłby tekst odczytany z naszego `.tex` pliku wejściowego.

Jak pokazano na poniższym diagramie, TeX wznawia odczyt `.tex` pliku wejściowego dokładnie w miejscu, w którym przerwał po przetworzeniu `\jobname`—po odczytaniu znaku spacji, ale przed odczytaniem znaku „.”. Kropka (.) w praktyce czeka na odczyt z bufora wejściowego TeX-a — niewielkiego obszaru pamięci TeX-a zaprojektowanego do przechowywania wiersza tekstu odczytanego z `.tex` pliku—TeX odczytuje i przetwarza Twój `.tex` plik po jednym wierszu, nie wczytuje całego pliku do pamięci.

Podczas studiowania poniższej grafiki czytaj od dołu i przesuwaj się w górę, aby śledzić przebieg procesu.

![Jak TeX rozwija \jobname](/files/da2c1b17253fb3faca3eee314fff4296d0b36820)

Nawiązując do naszej dyskusji o rozszerzaniu, możemy zauważyć, że rozwinięcie `\jobname` spowodowało, że `\jobname` polecenie (token) zostało *usunięte* usunięte z wejścia i *zastąpione* zastąpione tokenami powstałymi w wyniku rozszerzenia: tymczasową listą tokenów wygenerowaną w celu przechowania nazwy `.tex` pliku.

Polecenia rozszerzalne (takie jak `\jobname`) nie są jedynymi prymitywami TeX-a, które „po cichu” tworzą i wykorzystują listy tokenów, aby osiągnąć swój efekt. Na przykład polecenia `\uppercase` i `\lowercase` oba tworzą wewnętrzne listy tokenów, aby zmienić wielkość liter swojego argumentu. Gdy praca nad zmianą wielkości liter zostanie zakończona, TeX przełącza się na odczyt tokenów znakowych z list tokenów wygenerowanych przez te polecenia. Listy tokenów są jedynym mechanizmem TeX-a do „przechowywania danych tokenowych” — poza zapisywaniem danych do fizycznego pliku na dysku.

### Źródła tokenów: TeX jest mistrzem żonglerki

Gdy TeX przetwarza typowy dokument, musi obsługiwać *wieloma* źródeł tokenów: wejścia pochodzącego z licznych fizycznych plików na dysku i niezliczonych wewnętrznych list tokenów tworzonych podczas przetwarzania. W tej sekcji bardzo krótko zbadamy, jak TeX zdołuje „żonglować” tymi źródłami wejścia.

Załóżmy, że chcemy prostego makra, które składa nazwę naszego `.tex` plik:

```
    \def\myfile{Nazwa mojego pliku to \jobname .tex}
```

Później, w pewnym momencie w naszym `.tex` pliku wywołujemy makro `\myfile`: tymczasowo TeX przełącza się z tworzenia/odczytywania tokenów za pośrednictwem tekstu w Twoim pliku tekstowym (`.tex`) do odczytywania tokenów z `\myfile` definicji (listy tokenów) przechowywanej w jego pamięci. Gdy TeX wykonuje `\myfile` makro (przetwarza jego tokeny) wykryje token reprezentujący `\jobname` polecenie, którego rozwinięcie tworzy jeszcze jedną, tymczasową listę tokenów, z której TeX musi odczytywać tokeny. Nawet w tym prostym scenariuszu TeX musi zarządzać trzema źródłami wejścia:

1. stronie `.tex` pliku tekstowego zawierającego `\myfile` makro;
2. listy tokenów przechowującej definicję `\myfile` makro;
3. listy tokenów utworzonej przez `\jobname` polecenie wewnątrz `\myfile` makra.

Gdy TeX przetwarza dokument, nieustannie przełącza się między źródłami wejścia: fizycznymi plikami i listami tokenów, więc jak TeX to śledzi? Odpowiedź brzmi, że wewnętrznie silniki TeX-a utrzymują tak zwany [stos wejścia](https://en.wikipedia.org/wiki/Stack_\(abstract_data_type\)) który działa jak rodzaj „pamięci”, pozwalając TeX-owi pamiętać, co robił (z jakiego źródła odczytywał), gdy przełącza się między źródłami wejścia.

Nie zagłębiając się zbytnio w szczegóły, wewnętrzny kod w silnikach TeX-a używa globalnej zmiennej o nazwie `curinput` (bieżące wejście), która między innymi informuje TeX, czy obecnie czyta z fizycznego pliku czy z listy tokenów. `curinput` wskazuje TeX-owi również lokalizację (w bieżącej liście tokenów lub jej buforze tekstowym), z której powinien pobrać następny token. Jeśli TeX czyta z listy tokenów `curinput` rejestruje też, jaki typ listy tokenów jest przetwarzany — np. listę tokenów przechowywaną jako makro albo to, czy tokeny te powstały z innego źródła.

W razie potrzeby `curinput` zmienna zostanie zmieniona tak, aby wskazywać nowe źródło wejścia, a bieżący „stan wejścia” TeX-a (źródło i położenie) zostanie zapisany na stosie wejścia, aby TeX mógł później wrócić dokładnie do tego miejsca (pozycja w `.tex` pliku lub następny token na liście tokenów). Gdy nowe źródło wejścia zostanie wyczerpane (np. na liście tokenów nie będzie już żadnych tokenów albo zostanie osiągnięty koniec pliku), zostaje ono zdjęte ze stosu i `curinput` jest aktualizowane, aby zapewnić, że TeX powróci do pobierania tokenów z poprzedniego źródła.

## Zagłębianie się głębiej (opcjonalna lektura)

Poniższe sekcje dostarczają dodatkowych informacji w tle dla czytelników, którzy lubią szczegóły.

### Prawdziwe listy tokenów

Poniższa grafika została wygenerowana przy użyciu niestandardowej kompilacji TeX-a Knutha w Overleaf, która zapewnia dostęp do wewnętrznych danych i struktur danych TeX-a. Ta ilustracja listy tokenów rozwija uproszczoną wersję przedstawioną powyżej i zawiera dodatkowe dane, takie jak pokazanie znaków wygenerowanych przez `\jobname` mają kod kategorii 12, a nie zwykły kod kategorii 11. Na tym diagramie „node” to po prostu nazwa nadana jednostce pamięci używanej przez TeX-a.

![Wewnątrz listy tokenów TeX-a](/files/224dd7aa915b2259e2f1f51d501f7d2913849f05)

### Jak TeX odczytuje i przetwarza \jobname

Także, dla kompletności, oto przegląd „procesów myślowych” TeX-a, gdy wykrywa `\jobname` w naszym wejściowym `.tex` pliku. Na tej grafice widzimy, jak TeX wykrywa znak ucieczki (`\` o kodzie kategorii 0), przetwarza ciąg znaków `jobname`, generuje token i wyszukuje znaczenie `\jobname` polecenia, przy czym TeX odkryje, że ma kod polecenia > 100, co wskazuje, że jest to polecenie rozszerzalne.

![Jak TeX skanuje i przetwarza \jobname](/files/1e8f4d10768a86df00c9195e2117802508731d74)

[Część 1](/latex/pl/artykuly-szczegolowe/19-how-does-expandafter-work-an-introduction-to-tex-tokens.md) [Część 2](/latex/pl/artykuly-szczegolowe/22-how-does-expandafter-work-the-meaning-of-expansion.md) [Część 3](/latex/pl/artykuly-szczegolowe/21-how-does-expandafter-work-tex-uses-temporary-token-lists.md) [Część 4](/latex/pl/artykuly-szczegolowe/20-how-does-expandafter-work-from-basic-principles-to-exploring-tex-s-source-code.md) [Część 5](/latex/pl/artykuly-szczegolowe/17-how-does-expandafter-work-a-detailed-macro-case-study.md) [Część 6](/latex/pl/artykuly-szczegolowe/18-how-does-expandafter-work-a-detailed-study-of-consecutive-expandafter-commands.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/pl/artykuly-szczegolowe/21-how-does-expandafter-work-tex-uses-temporary-token-lists.md?ask=<question>&goal=<endgoal>
```

`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.
