> 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/fr/articles-approfondis/54-what-is-a-tex-token-list.md). # Qu’est-ce qu’une liste de jetons TeX ## Alors, qu’est-ce qu’une « liste de jetons TeX » ? Dans un [article précédent](/latex/fr/articles-approfondis/53-what-is-a-tex-token.md)—qui fait également partie de cette [série sur les aspects techniques de bas niveau de TeX](/latex/fr/articles-approfondis/01-a-new-series-of-articles-tex-tokens-and-related-concepts-but-why-and-how.md)—nous avons exploré les processus par lesquels TeX analyse votre `.tex` fichier pour générer de nouveaux jetons : nous avons examiné la nature fondamentale d’un jeton TeX et la manière dont TeX les crée (voir [Qu'est-ce qu'un « jeton TeX » ?](/latex/fr/articles-approfondis/53-what-is-a-tex-token.md)). Dans cet article de suivi, nous examinons les *liste de jetons*s : que sont-elles et comment les moteurs TeX les créent-ils / les utilisent-ils ? Acquérir une compréhension des listes de jetons peut être délicat, car elles sont stockées profondément dans les mécanismes internes de TeX : ces détails sont cachés à l’utilisateur — bien qu’aujourd’hui cela ne soit pas toujours vrai si vous faites de la programmation plus avancée avec LuaTeX. Mais, pour l’instant, vous pouvez commencer à considérer les listes de jetons comme la manière dont TeX stocke une série de valeurs entières, où chaque entier est un jeton dérivé d’un caractère ou d’une commande que TeX a lu dans votre fichier d’entrée. Les listes de jetons jouent un rôle central dans le fonctionnement interne de TeX, souvent de façons surprenantes, par exemple dans le fonctionnement interne de commandes telles que `\uppercase` et `\lowercase`. Une utilisation particulièrement importante des listes de jetons consiste à stocker et exécuter des macros, un sujet que nous examinerons en détail dans un futur article de cette série. ### TeX reçoit ses entrées depuis des fichiers et des listes de jetons Les moteurs TeX disposent de trois sources d’entrée — dont deux que vous connaissez peut-être : * des fichiers texte physiques stockés sur disque ; * du texte qu’un utilisateur saisit dans le terminal (ligne de commande) ; mais il possède aussi une troisième manière de lire / d’obtenir des entrées : les listes de jetons ! Les listes de jetons sont, en fait, un mécanisme interne de stockage de données que TeX utilise dans le cadre de ses opérations. Puisque les listes de jetons de TeX servent de « mécanisme de stockage » pour des jetons créés auparavant, il est logique que TeX puisse les réutiliser comme autre source d’entrée. Lorsqu’il devient nécessaire de prendre l’entrée suivante depuis une liste de jetons particulière (ou que TeX reçoit l’instruction de le faire), TeX suspend temporairement la lecture des entrées d’un fichier physique (c.-à-d. la création de *nouveaux jetons*) et bascule vers l’obtention de ses entrées depuis *jetons existants*: l’emplacement en mémoire où est stockée la liste de jetons. Il est clair qu’avec une liste de jetons, le processus d’analyse et de génération des jetons a déjà eu lieu ; TeX doit donc seulement examiner chaque jeton de la liste et décider quoi faire de chacun. À titre d’exemple rapide, la primitive TeX de bas niveau `\toks` commande vous permet de créer une liste de jetons que TeX enregistre en mémoire pour une réutilisation ultérieure : ```latex \toks100={Hello} ``` Pour récupérer ces jetons (c.-à-d. indiquer à TeX de les traiter comme sa prochaine source d’entrée), vous émettriez une commande telle que ```latex \the\toks100 ``` Cela fera passer TeX de la création de nouveaux jetons depuis votre fichier d’entrée à l’obtention des suivants depuis l’endroit où ces jetons (créés par `\toks`) sont stockés — dans ce que l’on appelle un *registre de jetons* qui n’est qu’un emplacement de mémoire interne connu de TeX (ici, il s’agit du registre 100). En outre, des listes de jetons peuvent être générées en interne, à la volée, par un certain nombre de commandes TeX. Un exemple est la commande `\jobname` qui génère une série de jetons de caractères — un jeton pour chaque caractère du nom du fichier principal que TeX traite. Un autre exemple est la `\string` commande ; par exemple ```latex \string\mymacro ``` génère une série de jetons de caractères pour chaque lettre du nom `\mymacro`—y compris le caractère initial `\` caractère. Nous examinerons de plus près certaines « commandes génératrices de jetons » à la fin de cet article. ## Liste de jetons : explication par analogie À moins d’avoir une expérience de la programmation et/ou quelques connaissances en informatique, les « listes de jetons » peuvent être un concept quelque peu flou et, peut-être, un peu déroutant. Cependant, si vous souhaitez devenir compétent dans l’écriture de macros TeX/LaTeX, une bonne compréhension de sujets tels que les jetons TeX, les listes de jetons et les codes de catégorie (`\catcode`) s’avérera extrêmement utile. Dans cette section, nous allons utiliser une analogie pour expliquer / illustrer les idées et principes fondamentaux d’une liste de jetons TeX : la manière dont TeX stocke les jetons en mémoire. Cela vaut la peine de prendre le temps de lire ce qui suit, car les listes de jetons sont un aspect *fondamental* de TeX et méritent d’être comprises un peu plus en détail. ### Listes de jetons : une analogie (expérience de pensée) Nous allons mener une « expérience de pensée » afin de fournir une base permettant de comprendre les listes de jetons TeX. Imaginez que vous ayez accès à un grand ensemble de récipients, par exemple des centaines de boîtes métalliques — nous ne pouvons pas employer le terme « boîte » pour décrire les récipients de notre expérience de pensée car, bien sûr, « boîte » a une signification très précise en TeX, totalement sans rapport avec notre discussion ici. Nous appellerons donc nos récipients des « Boîtes », chacune d’elles : * porte un numéro d’identification unique imprimé sur sa face extérieure ; * est divisée (à l’intérieur) en deux compartiments. Ces deux compartiments sont conçus comme suit : * le compartiment de gauche contient l’élément que vous souhaitez mettre dans la Boîte ; * le compartiment de droite est conçu pour contenir une feuille de papier sur laquelle vous pouvez écrire un seul nombre : le numéro identifiant une autre Boîte. ![test](/files/e8818cb83fd1121833d81cf45e4e051cc049b722) Supposez que vous disposiez d’une collection de, disons, 5 éléments et que vous souhaitiez stocker cette collection dans ces Boîtes ; mais, hélas, chaque Boîte ne peut contenir qu’un seul élément du type que vous souhaitez stocker. Pour simplifier, supposons que nous voulions stocker 5 cercles colorés : ![{{{alt}}}](/files/1610b4667ea52241d780cc3a7069b44693972628) En outre, lorsque vous revenez récupérer ces éléments de votre système de stockage (les Boîtes), ces éléments doivent *doit* être récupérés / trouvés dans un ordre particulier — l’ordre dans lequel ils ont été stockés : cette séquence doit être préservée. Comment y parvenir ? Nous pouvons tirer parti du fait que chaque Boîte : * porte un numéro d’identification unique sur sa face extérieure ; * possède 2 compartiments — nous n’en utiliserons qu’un pour contenir notre élément, l’autre contenant une feuille de papier sur laquelle est inscrit le numéro d’une autre Boîte. Nous supposerons que chaque Boîte est vide — mais rien ne vous empêche d’ouvrir une Boîte donnée pour vérifier si elle est vide ; si ce n’est pas le cas, essayez la suivante jusqu’à trouver une Boîte vide. Nous pourrions procéder comme suit. Mettez notre premier élément (cercle vert foncé) dans l’une de nos Boîtes (par exemple, la Boîte 124) et notez le numéro de cette première Boîte — peu importe le numéro de cette première Boîte, l’important est de le noter quelque part et de le conserver pour un usage ultérieur. ![{{{alt}}}](/files/6415089fb60cb42196a20cde2d136248aa17c4e9) Trouvez une deuxième Boîte — n’importe quel numéro de Boîte (par exemple, la Boîte 432) — et notez son numéro. Écrivez le numéro de cette deuxième Boîte (432) sur une feuille de papier et placez cette note *dans la première Boîte* (Boîte 124). Nous plaçons notre deuxième élément (cercle vert clair) dans la deuxième Boîte. Nous avons donc actuellement la situation suivante : * une note écrite — non stockée dans une Boîte — indiquant que la première Boîte porte le numéro 124 (elle contient notre premier élément) ; * dans la Boîte 124, nous avons ajouté une autre note indiquant que l’élément suivant se trouve dans la Boîte 432. En substance, nous avons *lié* nos deux premières Boîtes : nous savons où commencer (Boîte 124) et qu’une note dans la Boîte 124 nous indique quelle Boîte contient l’élément suivant (Boîte 432). ![{{{alt}}}](/files/5120705f79348acadf61d75848830e5ab9633313) Nous trouvons ensuite une troisième Boîte, écrivons son numéro (par exemple, Boîte 543) sur une feuille de papier et plaçons celle-ci dans la *deuxième* Boîte (numéro 432). Nous plaçons ensuite notre troisième élément (cercle rouge) dans la troisième Boîte. Nous avons maintenant relié trois Boîtes dans la séquence : notre point de départ, Boîte 124 (cercle vert foncé) → Boîte 432 (cercle vert clair) → Boîte 543 (cercle rouge) →… ![{{{alt}}}](/files/ce6151501034f0a994e5922df5764ee89c2bd1f0) Répétez ce processus pour les deux derniers éléments (cercles bleu clair et bleu foncé) en utilisant la Boîte 213 (cercle bleu clair) et la Boîte 102 (cercle bleu foncé). ![{{{alt}}}](/files/7612c27b008af559757c40406660c0da5591356a) Nous avons maintenant les 5 Boîtes toutes reliées entre elles (en utilisant l’identifiant numérique de chaque Boîte) et pouvons récupérer tous nos éléments stockés — dans le bon ordre — simplement en visitant chaque Boîte à tour de rôle, en retirant notre élément et en regardant la note qui nous indique quelle Boîte contient l’élément suivant. ### Qu’en est-il du dernier élément de notre liste (Boîte 102) ? Pourquoi devrions-nous nous préoccuper de celui-ci en particulier ? Jusqu’à présent, nous avons stocké chaque élément dans une Boîte, accompagné d’une note indiquant quelle Boîte contient l’élément suivant : pour le dernier élément de notre liste, que devrait dire cette note — puisqu’il n’y a pas de Boîte suivante. Lorsque nous atteignons l’élément final (la Boîte), il doit être évident que cette Boîte (contenant le dernier élément) est l’élément final de notre liste — nous n’avons pas besoin de chercher une autre Boîte, car il n’y en a pas. Une façon de faire est de placer un numéro de Boîte « spécial » à l’intérieur de notre dernière Boîte (102). Nous pouvons utiliser le numéro de notre choix, à condition de choisir un numéro unique qui ne soit pas celui d’une Boîte réelle — par exemple « Boîte -1 », « Boîte 0 » : peu importe, tant que nous savons que « Boîte -1 » ou « Boîte 0 », etc., nous indique immédiatement d’arrêter de chercher : nous n’avons plus besoin de chercher de Boîtes, car c’est la dernière et il n’y a donc plus d’éléments à récupérer. ### Des « éléments » et « Boîtes » aux jetons et à TeX Nous devons maintenant passer de notre analogie à une description plus proche de la réalité de TeX. Premièrement, au lieu de stocker des cercles de différentes couleurs dans nos Boîtes imaginaires, il devrait être clair que nous pourrions considérer ces Boîtes comme stockant des jetons TeX : de simples entiers. C’est la partie la plus facile du transfert de notre analogie vers le domaine du logiciel (TeX). Mais quel pourrait être l’équivalent logiciel de nos Boîtes physiques numérotées et munies de « compartiments » ? Nous ne voulons pas trop nous aventurer dans les concepts de programmation, mais vous pouvez considérer nos « Boîtes » comme représentant quelques octets de mémoire informatique qui ont été « empaquetés » dans une unité de stockage pratique. L’utilisation, dans notre analogie, d’un identifiant numérique pour chaque Boîte peut être considérée comme l’emplacement dans la mémoire informatique où se trouve chaque petit paquet de mémoire. Dans TeX lui-même, ces petits paquets de stockage sont appelés des « mots mémoire » — un terme qui reflète l’époque à laquelle TeX a été créé (les années 1970). Ces « mots mémoire » constituent l’élément fondamental utilisé dans TeX, mais nous n’avons pas besoin de les explorer davantage ici — quiconque souhaite plus de détails peut consulter un article sur [le blog personnel de l’auteur](http://www.readytext.co.uk/?p=3537). En termes de programmation informatique, ce dont nous avons parlé s’appelle une [*liste chaînée*](https://en.wikipedia.org/wiki/Linked_list): une liste de jetons TeX est une liste chaînée construite à partir des conteneurs de stockage de TeX appelés *mots mémoire* où chaque mot mémoire peut être utilisé pour stocker : * a *valeur*: la valeur du jeton (un entier) ; * a *lien*: l’emplacement mémoire du mot mémoire suivant contenant le jeton suivant de notre liste. ## Où TeX utilise-t-il des listes de jetons ? Partout ! Cela est vrai parce qu’une définition de macro TeX/LaTeX (par exemple une commande LaTeX) est stockée sous la forme d’une liste de jetons (légèrement spécialisée) — spécialisée en ce sens qu’elle contient des jetons que vous ne voyez pas dans les listes de jetons « standard » (liés à la correspondance des paramètres de macro, etc.). Ne vous en préoccupez pas, car nous aborderons ces détails dans un futur article. ### Un exemple de macro Une macro peut être considérée comme composée de trois parties : ``` \def\{} ``` Notez qu’au lieu de `\def` vous auriez pu utiliser `\edef`, `\gdef` ou `\xdef`. **Note aux utilisateurs de LaTeX**: Ici, nous définissons des macros en utilisant des commandes TeX brutes de bas niveau (appelées *primitives*). Les utilisateurs de LaTeX seront plus familiers avec la création de macros via la commande LaTeX `\newcommand` (qui est elle-même une macro). Lorsque vous demandez à TeX de créer (définir) une macro, il crée un jeton qui représente le `` et un *liste de jetons* qui représente la combinaison `` et ``. TeX stocke soigneusement l’ensemble afin que le jeton représentant `` soit lié à la liste de jetons représentant sa définition (`` et ``). Par exemple, si nous définissons `\mymacro` comme ceci : ```latex \def\mymacro abc #1 defz{I typed "#1"!} ``` Nous pouvons constater que ses éléments constitutifs sont : * `` = `mymacro` * `` = `abc #1 defz` * `` = `J’ai tapé « #1 » !` Par exemple, vous pourriez appeler `\mymacro` comme ceci : ```latex \mymacro abc THIS TEXT defz ``` ce qui produit `J’ai tapé « THIS TEXT » !` composé — les `abc` et `defz` êtes *pas* ne sont pas composés. `abc` et `defz` sont des séquences de jetons de caractères utilisées pour *délimiter* le paramètre de macro `#1` et sont absorbés et éliminés lorsque votre appel de macro est traité avec succès par TeX. Lorsque vous avez défini `\mymacro`, le modèle de jetons contenu dans l’élément stocké agit comme un « gabarit » que TeX peut utiliser pour déterminer : * quels jetons de votre entrée sont les jetons délimiteurs ; * quels jetons de votre entrée constituent réellement le ou les paramètres de votre macro (ici, ce que vous utilisez pour `#1` dans votre appel de `\mymacro`). Vous devez appeler `\mymacro` par un `` en contenant des délimiteurs identiques à ceux utilisés pour la définir — ce qui inclut l’utilisation de délimiteurs de caractères ayant des codes de catégorie identiques. Si les délimiteurs dans le `` utilisé pour appeler `\mymacro` sont différents de ceux utilisés pour la définir (le « gabarit » stocké en mémoire), alors TeX peut devenir assez confus — lorsqu’il essaie de traiter `\mymacro` il ne pourra pas faire correspondre le « gabarit » qu’il a enregistré en mémoire. Lorsque TeX voit que vous appelez une macro, il analyse votre texte d’entrée pour créer de nouveaux jetons et tente, jeton par jeton, de les faire correspondre à la liste de jetons `` gabarit stockée dans le cadre de la définition de votre macro. Si les délimiteurs utilisés dans votre texte d’entrée produisent une série de jetons qui ne correspondent pas à ceux stockés dans le « gabarit », TeX générera généralement une erreur. TeX est très exigeant — rappelez-vous que les jetons de caractères sont une combinaison de code de caractère et de code de catégorie : si vous modifiez le code de catégorie d’un caractère, vous obtenez une valeur de jeton différente à partir de ce caractère. Supposons que nous modifiions le code de catégorie de `z` à, disons, 12 — normalement il vaut 11 — et essayions d’appeler notre macro ainsi : ```latex \catcode`z=12 \mymacro abc THIS TEXT defz more text here... ``` Cette fois, cela ne fonctionnera pas parce que le code de catégorie de `z` a été modifié. Vous verrez une erreur telle que celle-ci : ```latex Argument incontrôlé ? THIS TEXT defz ! Paragraphe terminé avant que \mymacro soit complet. <à relire> \\par l.22 ``` Lorsque TeX lit et analyse le `z` dans `defz` il ne peut pas le reconnaître comme constituant la fin de `\mymacro`de `` utilisé dans votre fichier d’entrée. Jusqu’à ce qu’il voie cet élément erroné, `z` TeX avait correctement fait correspondre les 3 premiers caractères `def` mais ce `z` (avec le code de catégorie 12) perturbe l’analyse de TeX. En supposant que `z` avait un code de catégorie de 11 lorsque nous avons *défini* `\mymacro`: cela aurait pour résultat que la valeur de jeton 256×11 + 122 = 2938 soit stockée dans le cadre de la définition de `\mymacro`(c.-à-d. stockée dans le « gabarit »). Toutefois, avec le code de catégorie 12, `z` créera désormais une valeur de jeton de 256×12 + 122 = 3194. Puisque la valeur de jeton (pour `z`) lue depuis votre entrée (valeur 3194) ne correspond pas au jeton `z`-contenu dans l’élément stocké `` gabarit de liste de jetons (valeur 2938), TeX continuera d’analyser votre entrée. TeX continuera à analyser le texte qui suit votre macro (*plus de texte ici* ...) afin de rechercher des jetons supplémentaires — en essayant de faire correspondre le gabarit stocké aux jetons qu’il trouve dans votre entrée. Il ne trouvera probablement pas le bon modèle de jetons et des erreurs en résulteront, car TeX « dépasse » votre entrée et lit à tort du texte supplémentaire afin de créer des jetons additionnels — ces jetons supplémentaires n’auraient pas dû être lus à ce stade et généreront presque certainement une erreur. Nous examinerons cela plus en détail dans un futur article. ## Autres utilisations des listes de jetons D’autres commandes utilisées pour créer / stocker des listes de jetons incluent : ```latex \toks={...} \everypar={...} \everymath={...} \everydisplay={...} \everyhbox={...} \everyvbox={...} \output={...} \everyjob={...} \everycr={...} \errhelp={...} ``` Chacune de ces commandes crée une liste de jetons à partir des caractères et commandes situés entre les accolades « {...} », et cette liste de jetons est destinée à être réutilisée dans certaines circonstances. Par exemple, `\everypar={...}` crée et stocke un ensemble de jetons (une liste de jetons) que TeX injecte dans l’entrée juste avant de commencer un nouveau paragraphe. ## Utilisations cachées des listes de jetons : exemples Dans cette dernière section, nous examinerons quelques exemples pratiques d’utilisation de listes de jetons d’une manière à laquelle vous ne vous attendriez peut-être pas. ### Exemple 1 : \uppercase{...} et \lowercase{....} — listes de jetons temporaires Outre les commandes explicites de génération de listes de jetons, il existe des circonstances où TeX génère une liste de jetons interne cachée et temporaire afin d’effectuer un traitement spécial. Rappelez-vous que lorsque TeX lit / traite vos caractères ou commandes d’entrée, ils sont transformés en jetons : l’élément fondamental avec lequel travaillent les moteurs TeX. Les commandes suivantes en sont un bon exemple : `\uppercase{...}` ou `\lowercase{...}` car leur fonctionnement peut, lors de la première rencontre, être assez déroutant. Une fois que vous comprenez ce qu’elles font — plus profondément dans TeX et de façon invisible pour l’utilisateur — leurs opérations deviennent beaucoup plus faciles à comprendre. Supposons que vous ayez une simple série de lettres que vous souhaitiez mettre en majuscules — par exemple abcde et la convertir en ABCDE. Eh bien, c’est assez simple avec la commande TeX `\uppercase` commande : ```latex \uppercase{abcde} ``` fera en sorte que TeX produise `ABCDE`. Supposons maintenant que nous voulions enregistrer notre simple série de lettres pour l’utiliser plus tard — c.-à-d. que nous ne voulons pas les produire immédiatement, nous utiliserons donc le seul mécanisme *interne* de TeX — et non un mécanisme externe (fichier) — pour enregistrer des données : utiliser une liste de jetons. Nous pouvons le faire soit en créant une macro, soit en utilisant une commande explicite de liste de jetons : ```latex \toks100={abcde} \def\mychars{abcde} ``` Ensuite, à un certain moment, vous pourriez décider de réutiliser votre série de lettres, mais cette fois en majuscules ; vous essayez donc ```latex \uppercase{\the\toks100} ``` et ```latex \uppercase{\mychars} ``` Mais, hélas, aucune de ces deux solutions ne fonctionne. Pourquoi ? ### Listes de jetons secrètes ! Pour comprendre comment les commandes `\uppercase{...}` `\lowercase{...}` fonctionnent réellement, j’ai dû examiner les mécanismes internes de TeX ; l’explication suivante découle donc de cette démarche. Lorsque TeX détecte l’une ou l’autre des commandes `\uppercase{}` ou `\lowercase{}` dans votre entrée, la première chose que fait TeX est de créer une liste de jetons interne (temporaire) à partir du `` enfermé entre les caractères « { » et « } » qui suivent les `\uppercase{...}` ou `\lowercase{...}` commandes — cette liste de jetons temporaire est interne à TeX. Un point crucial, central pour comprendre comment `\uppercase{}` et `\lowercase{}` fonctionnent réellement, est que les commandes ou macros contenues dans le `` ne sont pas *expansé*exécutées : tout ce que fait TeX est de générer des jetons à partir des caractères et commandes placés entre `{...}`. Pendant l’opération de `\uppercase{}` ou `\lowercase{}` rien entre les accolades n’est exécuté : tout est simplement transformé en jetons. Après les `` dans le `{...}` a été converti en une liste de jetons (temporaire), TeX réexamine ensuite chaque jeton de cette liste et vérifie s’il s’agit d’un jeton *caractère* de caractère *commande* de commande (en utilisant la valeur numérique du jeton). Si TeX détecte un jeton de caractère, il modifie ce jeton pour ajuster la casse du caractère (selon que `\uppercase` ou `\lowercase` est en cours de traitement). TeX ignore simplement les jetons de commande et ne « regarde pas à l’intérieur » des jetons de commande pour voir ce qu’ils représentent ou contiennent (par exemple, une macro contenant des caractères) — ils sont simplement ignorés : seuls les jetons de caractères sont réellement traités / affectés par les opérations de changement de casse. Ainsi, par exemple, si nous émettons une commande TeX telle que `\uppercase{abcde}` TeX créera une liste de jetons à partir de `abcde` ne contenant que des jetons de caractères : ils sont tous ajustés afin de créer une série de jetons modifiés représentant A, B, C, D et E. Ces jetons modifiés sont réinjectés dans le processeur d’entrée de TeX, ce qui entraîne la composition de `ABCDE` Toutefois, si nous avons stocké nos caractères *dans une macro*—par exemple `\def\mychars{abcde}`—et essayons de les convertir en majuscules ainsi : ```latex \uppercase{\mychars} ``` alors cela échouera et abcde sera composé — et non ABCDE comme vous pourriez vous y attendre. Si nous essayons ensuite de stocker nos caractères dans une liste de jetons telle que `\toks0={abcde}` et faisons `\uppercase{\the\toks0}` alors, une fois encore, `\uppercase` échouera parce que la liste de jetons sera entièrement composée de jetons qui ne sont pas affectés par `\uppercase`. En prenant l’exemple de notre macro, `\mychars`, après que TeX a détecté `\uppercase` dans l’entrée, TeX recherche la signification de `\uppercase` et l’exécute, en créant une liste de jetons temporaire à partir de `{\mychars}`. Il est clair que cette liste de jetons temporaire ne contient qu’un seul jeton, qui n’est pas un jeton de caractère mais un jeton représentant notre commande de macro `\mychars`: par conséquent, aux fins de l’exécution de `\uppercase`, ce jeton est ignoré —`\mychars` ne représente pas un jeton de caractère. Cependant, comme indiqué ci-dessus, une fois que `\uppercase` a terminé son travail, la liste de jetons temporaire (créée par l’action de `\uppercase`) est réinjectée dans le mécanisme complet de traitement des entrées (analyse) de TeX. Lorsque TeX relit cette liste de jetons, il détecte un jeton qui représente notre `\mychars` macro, que TeX exécute (développe) et qui génère une série de caractères pour composer abcde — toujours en minuscules parce qu’ils étaient « emballés » dans une macro et donc invisibles aux actions de `\uppercase`. Une fois que TeX a réexaminé la liste de jetons temporaire créée pour `\uppercase{...}` ou `\lowercase{...}`, et traité les éventuels jetons de caractères, il bascule alors vers l’utilisation de cette liste de jetons temporaire comme source d’entrée : il compose les caractères (jetons de caractères traités) et exécute les commandes et macros. ### Comment corriger cela ? Parce que `\uppercase{...}` ou `\lowercase{...}` n’agira que sur les jetons de caractères ; nous avons donc besoin d’un moyen de « forcer le dépaquetage » des caractères contenus dans notre macro `\mychars` (ou contenus dans un `\toks` registre) avant que `\uppercase{...}` ou `\lowercase{...}` agisse sur eux. Par « dépaquetage », nous entendons en réalité le processus de TeX consistant à *extension*: * remplacer une commande TeX/LaTeX par la *séquence* de jetons *dont cette commande* (*par exemple, une macro*) *est constituée,* ou * produisant la séquence de jetons qu’une commande est conçue pour *générer*. Un exemple de commande qui génère des jetons est `\jobname`, qui produit une séquence de jetons de caractères représentant le nom du fichier TeX principal en cours de traitement. #### Magie de niveau inférieur : scantoks(..., ...) Ici, nous sondons réellement certains recoins plus obscurs des mécanismes internes de TeX ; vous pouvez donc ignorer cette section, à moins que vous n’appréciiez les détails… Après que TeX a détecté `\uppercase` ou `\lowercase` dans le flux d’entrée, il exécute une fonction interne appelée `scantoks(..., ...)` dont le rôle est de générer la liste de jetons à partir des éléments entre le « { » ouvrant et le « } » fermant — comme indiqué, cette liste de jetons est ensuite examinée afin de détecter (puis d’ajuster) les éventuels jetons de caractères pour modifier la casse des caractères selon les besoins. Notez attentivement que nous faisons référence à `scantoks(..., ...)` en tant que fonction interne intégrée au code source des moteurs TeX — ici, il ne s’agit pas du nom d’une séquence de contrôle. Dans le cadre de son travail, `scantoks(..., ...)` peut recevoir l’instruction de développer ou non la liste de jetons qu’elle construit et, pour `\uppercase` et (`\lowercase`), elle ne développe pas les jetons : elle les crée simplement et les place dans une liste de jetons. L’une des premières choses que `scantoks(..., ...)` doit faire est de rechercher un « { » ouvrant (ou tout caractère de `\catcode` 1), car elle doit s’assurer que l’utilisateur n’a pas commis d’erreur de syntaxe et oublié le « { » ouvrant (ou tout caractère de code de catégorie 1) — car un caractère de code de catégorie 1 est requis pour délimiter le début d’une liste d’éléments à transformer en jetons. Et voici l’astuce : la tâche de recherche d’un « { » ouvrant déclenche `scantoks(..., ...)` afin d’exécuter le processus de développement de TeX, ce qui signifie que les exemples suivants fonctionneront : ```latex \let\ob={ \uppercase\ob abcde} \def\obb{\ob} \uppercase\obb xyz} ``` En prenant l’exemple de `\obb`, une macro, elle est reconnue comme une *commande extensible* et est dûment développée par TeX (via la fonction `scantoks(..., ...)` ) dans sa recherche d’une accolade ouvrante (tout caractère de code de catégorie 1). Cela signifie que nous pouvons utiliser l’«`\expandafter` astuce » pour atteindre notre objectif de « dépaqueter » nos caractères des limites de notre macro — c.-à-d. de la développer. Notez que `\expandafter` appartient aussi à la catégorie des *commande extensible*, donc TeX l’exécute ici et le laisse faire son travail dans le cadre de la recherche d’un « { » ouvrant (ou de tout caractère dont le code de catégorie est 1). Ainsi, si vous définissez : ```latex \toks0={abcde} \def\mychars{abcde} ``` Et faites ceci : ```latex \uppercase\expandafter{\mychars} \uppercase\expandafter{\the\toks0} ``` dans les deux cas, vous verrez désormais ABCDE composé parce que `\expandafter` provoque le « dépaquetage » (développement) de `\mychars` et `\the\toks0`— les deux aboutissent à `\uppercase` voyant un flux de jetons de caractères, qu’ils peuvent traiter pour modifier la casse. ### Exemple 2 : \string — davantage de listes de jetons temporaires En interne, TeX classe `\string` comme l’une de ses commandes dites « convert » : elle effectue l’opération de « conversion en texte ». Le `\string` commande est conçue pour convertir un jeton en une version textuelle lisible par l’humain — c’est-à-dire composer la chaîne de caractères lisible par l’humain à partir de laquelle ce jeton a été initialement créé. Par exemple `\string\hello` crée une liste temporaire de jetons qui contient les caractères \\, h, e, l, l, o — oui, y compris même le « \ » initial. Une fois cette liste de jetons créée, elle est relue par TeX et le texte de la commande «`\hello`» est composé—oui, y compris le « \ » si vous choisissez la police appropriée… Vous pouvez vous demander comment/pourquoi TeX peut composer le caractère d’échappement alors qu’il est généralement utilisé pour déclencher l’analyseur de TeX afin de créer un jeton de commande : pourquoi ne le fait-il pas ici ? La réponse tient aux codes de catégorie : d’habitude, un caractère « \ » a le catcode 0 (caractère d’échappement), mais lorsque `\string` génère sa liste interne de jetons, il fait quelque chose d’un peu différent. Lorsqu’il crée une liste de jetons de caractères, il attribue le code de catégorie 12 à tous les caractères, à l’exception du caractère espace, auquel il attribue le catcode 10 — rappelez-vous que les jetons de caractères sont calculés à partir de 256 × catcode + valeur ASCII. Ainsi, lorsque TeX relit (réinjecte) la liste temporaire de jetons que `\string` générée à partir de `\hello`, TeX *ne voit pas de caractère d’échappement* parce que le jeton correspondant au « \ » a été calculé avec un catcode 12 et non 0 : TeX traite simplement le « \ » comme un caractère ordinaire et le compose. À proprement parler, nous devrions probablement noter que TeX ne génère pas en réalité de jeton pour les caractères d’échappement lorsqu’il les détecte dans l’entrée. Une fois qu’il a reconnu un caractère de code de catégorie 0, ce caractère sert simplement à « déclencher » la génération d’un jeton de séquence de contrôle : une fois qu’il a déclenché TeX pour le faire, le caractère d’échappement a accompli son travail et n’est plus pris en compte. ### Note technique Une commande appelée `\showtokens{...}` (introduite par le moteur e-TeX) peut afficher des listes de jetons (dans le fichier journal). D’après le manuel e-TeX : > La commande `\showtokens{}` affiche la liste de jetons, et permet d’afficher des quantités qui ne peuvent pas être affichées par `\show` ou `\showthe`, par exemple : > > ```latex > \showtokens\expandafter{\jobname} > ``` ## En conclusion Dans la section 291 du code source de TeX (voir page 122 de [TeX : Le programme](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373)) Knuth décrit une liste de jetons comme suit : > « Une liste de jetons est une liste chaînée simple de nœuds d’un mot dans mem, où chaque mot contient un jeton et un lien. Les définitions de macros, les définitions de routine de sortie, les marques, `\write` les textes, et quelques autres choses sont mémorisés par TeX sous forme de listes de jetons, généralement précédées d’un nœud avec un compteur de références dans son champ « token\_ref\_count ». » À la première lecture, cela n’a peut-être pas été facile à comprendre, mais, espérons-le, cela a maintenant un peu plus de sens. --- # 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/fr/articles-approfondis/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.