turbo-editors/turbo-jspublic Fork 0
main
Commits
Clone
git clone https://git.rickub.com/turbo-editors/turbo-js.git
git clone ssh://git@rickub.com/turbo-editors/turbo-js.git

Host key fingerprint (ed25519): SHA256:iycHnxEyq0Q7uyVpB7JlznP0G7JrTPXLYRcAU5CSLhc — verify it before your first connect.

languages.md · 296 lines · 21.2 KBmarkdown Blame HistoryRaw
📦 Turbo JS 91999d1 k33g 10h ago1# Référence : langages colorés
2
3> Description neutre des fichiers que Turbo JS colore, de la façon dont il décide, et de ce que chaque scanner reconnaît.
4
5## Reconnaissance
6
7L'**extension** d'un fichier décide dès qu'elle est l'une de celles-ci :
8
9| Extension | Langage |
10| --- | --- |
11| `.js`, `.mjs`, `.cjs` | JavaScript |
12| `.json`, `.jsonc` | JSON |
13| `.toml` | TOML |
14| `.yaml`, `.yml` | YAML |
15| `.md`, `.markdown` | Markdown |
16| `.html`, `.htm` | HTML |
17| `.xml`, `.xsd`, `.xsl`, `.xslt`, `.svg`, `.plist`, `.csproj`, `.pom` | XML |
18| `.sh`, `.bash`, `.zsh` | Shell |
19| `.dockerfile`, `.containerfile` | Dockerfile |
20
21Les extensions sont comparées sans tenir compte de la casse, et seule la dernière compte : `notes.js.md` est du Markdown, `main.js.backup` n'est pas du JavaScript, et `main.test.js` est du JavaScript.
22
23Un fichier dont l'extension ne décide rien est ensuite cherché par son **nom**. Seuls les fichiers sans extension utile en ont besoin :
24
25| Nom | Langage |
26| --- | --- |
27| `Dockerfile`, `Containerfile` | Dockerfile |
28
29Un nom correspond sur sa totalité ou sur la partie avant le premier point, sans tenir compte de la casse — `Dockerfile`, `dockerfile` et `Dockerfile.dev` sont donc tous reconnus, tandis que `Dockerfile.md` est du Markdown, parce que l'extension est consultée d'abord.
30
31Un fichier que ni l'une ni l'autre table ne réclame est lu par sa **première ligne**. Un shebang nommant `node` en fait du JavaScript : un outil en ligne de commande écrit en JavaScript est un fichier sans extension dont la première ligne est `#!/usr/bin/env node`, et Node retire cette ligne avant de parser. Un shebang nommant un shell — `sh`, `bash`, `zsh`, `dash` ou `ksh` — en fait un script shell. L'interpréteur est reconnu comme élément de chemin ou comme argument d'`env`.
32
33| Première ligne | Résultat |
34| --- | --- |
35| `#!/usr/bin/env node` | JavaScript |
36| `#!/usr/local/bin/node` | JavaScript |
37| `#!/usr/bin/env -S node --no-warnings` | JavaScript |
38| `#!/bin/sh` | Shell |
39| `#!/usr/bin/env bash` | Shell |
40| `#!/usr/bin/env python3` | Non coloré |
41| Tout ce qui ne commence pas par `#!` | Non coloré |
42
43L'ordre est fixe — extension, puis nom, puis première ligne — et le premier qui décide l'emporte.
44
45Tout le reste est affiché en texte brut. Ce n'est pas une erreur — ouvrir un PNG dans l'éditeur n'est pas une faute, c'est juste non coloré. En particulier, **TypeScript (`.ts`, `.tsx`), JSX (`.jsx`) et CSS ne sont pas colorés** : le serveur de langage sert les fichiers `.ts` quand même, mais le scanner ici est pour JavaScript.
46
47## Classes
48
49Chaque scanner produit le même vocabulaire de classes, et chacune correspond à une clé de thème.
50
51| Classe | Clé de thème | Produite par |
52| --- | --- | --- |
53| `identifier` | `syntax.identifier` | JavaScript, JSON (un mot nu, qui n'est pas du JSON), TOML, shell, YAML, Dockerfile |
54| `keyword` | `syntax.keyword` | JavaScript, shell, HTML (doctype), XML, Dockerfile |
55| `type` | `syntax.type` | JavaScript (noms de classes et noms capitalisés), TOML (en-têtes de table), YAML (tags) |
56| `builtin` | `syntax.builtin` | JavaScript (les globales de la bibliothèque standard et de Node), shell (builtins et expansions), YAML (ancres et alias), Dockerfile (variables) |
57| `constant` | `syntax.constant` | JavaScript, JSON, TOML, shell, YAML, HTML et XML (entités) |
58| `function` | `syntax.function` | JavaScript, shell (la commande) |
59| `string` | `syntax.string` | tous |
60| `char` | `syntax.char` | JavaScript (littéraux d'expressions régulières) |
61| `number` | `syntax.number` | JavaScript, JSON, TOML, shell, YAML, Dockerfile |
62| `comment` | `syntax.comment` | JavaScript, JSON, TOML, shell, HTML, YAML, XML, Dockerfile |
63| `operator` | `syntax.operator` | JavaScript, TOML, shell, HTML, YAML (en-têtes de scalaires bloc), XML, Dockerfile |
64| `punctuation` | `syntax.punctuation` | JavaScript, JSON, TOML, shell, Markdown, YAML, Dockerfile |
65| `heading` | `syntax.heading` | Markdown |
66| `tag` | `syntax.tag` | HTML, XML |
67| `attribute` | `syntax.attribute` | JSON (clés), JavaScript (décorateurs), HTML, XML, Dockerfile (options) |
68| `emphasis` | `syntax.emphasis` | Markdown |
69| `link` | `syntax.link` | Markdown |
70
71JavaScript ne produit aucune portée `heading`, `tag`, `emphasis` ou `link`. Dans `turbo-classic`, `syntax.number` et `syntax.constant` sont tous deux magenta et `syntax.char` a le vert de `syntax.string`, si bien que `42` et `true` partagent une couleur là, et `/re/` et `"re"` aussi ; d'autres thèmes les séparent. Voir [écrire son propre thème](../how-to/write-a-theme.md) pour changer cela.
72
73## JavaScript
74
75Écrit à la main, dans `internal/jslang`, et enregistré sous le même nom que le scanner que turbo-core livre pour JavaScript, qu'il remplace. Ce qu'il ajoute à celui de la bibliothèque : les littéraux d'expressions régulières, la ligne de hashbang, les globales de Node, le nom après `function` et `class`, les noms privés, les décorateurs, et une majuscule initiale lue comme un nom de classe.
76
77**Deux constructions franchissent une ligne**, et sont portées à la ligne suivante : un commentaire bloc `/* … */` jusqu'à son `*/` fermant, et un littéral de gabarit `` `` `` jusqu'à son accent grave fermant. Aucune des deux ne s'imbrique. Une chaîne ordinaire `'…'` ou `"…"` ne franchit **pas** une ligne : une chaîne non terminée est colorée jusqu'à la fin de sa ligne, et la ligne suivante est de nouveau du code.
78
79| Reconnu | Comme |
80| --- | --- |
81| `as`, `async`, `await`, `break`, `case`, `catch`, `class`, `const`, `continue`, `debugger`, `default`, `delete`, `do`, `else`, `export`, `extends`, `finally`, `for`, `from`, `function`, `get`, `if`, `import`, `in`, `instanceof`, `let`, `new`, `of`, `return`, `set`, `static`, `super`, `switch`, `throw`, `try`, `typeof`, `var`, `void`, `while`, `with`, `yield`, et les réservés `enum`, `implements`, `interface`, `package`, `private`, `protected`, `public` | mot-clé |
82| `true`, `false`, `null`, `undefined`, `NaN`, `Infinity`, `this` | constante |
83| les globales de la bibliothèque standard — `Array`, `Object`, `Promise`, `Math`, `JSON`, `Map`, `Set`, `Symbol`, `BigInt`, `Error`, `TypeError`, `parseInt`, `setTimeout`, `structuredClone`, `fetch`, `URL`, … | builtin |
84| les globales de Node — `process`, `Buffer`, `console`, `require`, `module`, `exports`, `__dirname`, `__filename`, `setImmediate`, `performance`, `crypto` — et `document` et `window` du navigateur | builtin |
85| le nom après `function`, `function*` ou `async function` — `parse` dans `function parse(input) {}` | fonction |
86| le nom après `class` — `widget` dans `class widget extends Base {}` | type |
87| tout autre nom commençant par une majuscule ASCII — `Greeter`, `EventEmitter`, `MyError` — même devant un `(` | type |
88| tout autre nom immédiatement avant `(` — `compute(3)`, `obj.method()`, `this.#reset()` | fonction |
89| tout mot après `.` ou `?.`, quelle que soit son orthographe — `map.get(k)` une fonction, `options.default` un nom, `user?.class` un nom | propriété, jamais un mot-clé |
90| `get`, `set`, `static`, `of`, `from` et `as` devant un `(` — `get(key)` | fonction |
91| `#count`, un membre privé, `#` compris | identifiant, ou fonction devant `(` |
92| `@decorator`, `@observable.ref`, chemin pointé compris | attribut |
93| tout autre nom : une lettre Unicode, `_` ou `$`, puis des lettres, des chiffres et les mêmes — `x`, `$el`, `_`, `café`, `名前` | identifiant |
94| `"…"`, `'…'` avec les échappements par barre oblique inverse, sur une ligne | chaîne |
95| `` `` ``, interpolations `${…}` comprises, sur plusieurs lignes | chaîne |
96| `/…/gi`, un littéral d'expression régulière, drapeaux compris, là où le token précédent en permet un et qu'un `/` fermant existe sur la ligne | caractère |
97| `42`, `1_000`, `0xFF`, `0o17`, `0b1010`, `1.5e-3`, `2E+10`, `.5`, `10n`, `0xFFn` | nombre |
98| `//` jusqu'à la fin de la ligne ; `/* … */` et `/** … */` sur plusieurs lignes | commentaire |
99| `#!` sur la première ligne du fichier, jusqu'à sa fin | commentaire |
100| `...` | ponctuation, en une seule portée |
101| `?.` | opérateur, en une seule portée |
102| les suites de `+-*/%=<>!&\|^~?:` — dont `=>`, `??`, `===`, `**`, `>>>=` | opérateur |
103| `()[]{},;` et un `.` seul | ponctuation |
104
105**Une barre oblique divise après une valeur et ouvre une expression régulière partout ailleurs.** Après un nom, un nombre, une chaîne, un gabarit, une expression régulière, `)` ou `]`, un `/` est une division. Après un opérateur, `(`, `[`, `{`, `}`, `,`, `;`, `:`, un mot-clé, ou en début de ligne, il ouvre une expression régulière — **à condition qu'un `/` fermant existe sur la même ligne** ; sinon il divise, quoi qu'il y ait avant. Une expression régulière ne peut pas franchir une ligne, cette borne limite donc une mauvaise supposition à une ligne.
106
107**Un point rejoint un nombre seulement quand un chiffre le suit**, `1.toString()` est donc le nombre `1`, un point et une méthode. **Le signe après un `e` fait partie du nombre**, sauf dans un littéral hexadécimal, où `0xE+1` est une somme.
108
109**Un nom capitalisé est une classe par convention, pas par règle.** JavaScript vous laisse écrire `const Count = 1`, et il est coloré comme une classe quand même, tout comme `MAX_SIZE`. Les classes et les constructeurs sont ce que les gens capitalisent, et la couleur suit les gens.
110
111**Non reconnu**, chacun pour une raison énoncée :
112
113| Non reconnu | Parce que |
114| --- | --- |
115| Le code dans `${…}` d'un gabarit | Le colorer signifie que le scanner rentre en lui-même avec une profondeur d'imbrication à porter, pour une construction qui est d'habitude une courte expression ; tout le littéral est une chaîne |
116| Un accent grave dans `${…}` | Pour la même raison : il termine le gabarit trop tôt, et le code qui suit est coloré comme du code jusqu'à l'accent grave suivant |
117| Une expression régulière sans barre oblique fermante sur sa ligne | Elle ne peut pas en être une — le langage interdit un saut de ligne dans le littéral — la barre oblique divise donc |
118| JSX | `<div>` est lu comme un opérateur, un nom et un opérateur ; il n'y a pas de HTML dans le JavaScript ici |
119| Les annotations et les types de TypeScript | Un autre langage ; les fichiers `.ts` ne sont pas colorés du tout |
120| Les commentaires bloc imbriqués | JavaScript termine un commentaire bloc au premier `*/` ; une profondeur serait une affirmation sur un autre langage |
121| Une chaîne continuée par une barre oblique inverse finale | La chaîne s'arrête à sa ligne et la ligne suivante est du code ; la continuation est assez rare pour ne pas valoir d'être portée |
122| Si un nom en `SCREAMING_SNAKE_CASE` est une constante | La majuscule initiale dit classe, et rien dans l'orthographe ne sépare les deux conventions |
123| `#` comme commentaire | Il n'en est un que dans le hashbang, sur la première ligne ; partout ailleurs `#` commence un nom privé ou est enjambé |
124| Si un nom est lié dans cette portée | Rien ici ne lit plus d'une ligne à la fois ; c'est la question du serveur de langage, et [F1 y répond](../how-to/ask-about-code.md) |
125
126## JSON
127
128Écrit à la main, dans `internal/jslang/json.go`, trente lignes, parce que le langage fait trente lignes : des chaînes, des nombres, trois mots, six signes de ponctuation. C'est le langage dans lequel est écrit le manifeste de chaque projet Node, et turbo-core ne le colore pas.
129
130| Reconnu | Comme |
131| --- | --- |
132| `"name"` suivi d'un deux-points — une clé | attribut |
133| `"demo"` partout ailleurs — une valeur | chaîne |
134| `-12.5e+3`, `42`, `0.5` | nombre |
135| `true`, `false`, `null` | constante |
136| `{`, `}`, `[`, `]`, `,`, `:` | ponctuation |
137| `//` jusqu'à la fin de la ligne ; `/* … */` sur plusieurs lignes | commentaire |
138| tout mot nu — `undefined`, `NaN`, une clé sans guillemets | identifiant |
139
140**Une chaîne est une clé quand un deux-points la suit**, au-delà des espaces éventuels, et une valeur sinon. `{"a" 1}` colore `"a"` comme une valeur : ce n'est pas encore une clé.
141
142**Les commentaires sont tolérés, pas approuvés.** Le JSON strict n'en a pas ; `tsconfig.json`, les fichiers `.jsonc` et le fichier de réglages de chaque éditeur en ont, et un scanner qui les peindrait comme cassés aurait tort exactement dans les fichiers les plus susceptibles d'en contenir un.
143
144| Non reconnu | Parce que |
145| --- | --- |
146| Si le document est du JSON valide | Le scanner colore des tokens ; un mot nu sort comme un identifiant plutôt que d'arrêter la ligne, et une clé dupliquée ressemble à n'importe quelle autre |
147| Les chaînes entre apostrophes, les virgules finales et le reste de JSON5 | Pas du JSON ; un `'` est enjambé sans couleur |
148| Une chaîne non terminée qui s'arrête ailleurs qu'à sa ligne | Elle est colorée jusqu'à la fin de la ligne, comme une valeur, et la ligne suivante est de nouveau du JSON |
149
150## TOML
151
152| Reconnu | Comme |
153| --- | --- |
154| `# commentaire` | commentaire |
155| `[table]`, `[[tableau]]` | le nom comme type, les crochets comme ponctuation |
156| `clé =` | identifiant, puis opérateur |
157| `"basique"`, `'littérale'`, `"""multiligne"""`, `'''multiligne'''` | chaîne |
158| `true`, `false` | constante |
159| nombres, dates, heures, `inf`, `nan` | nombre |
160
161## YAML
162
163Un fichier compose, un manifeste Kubernetes et un workflow de CI sont tous cela : il n'y a pas de dialecte séparé, parce qu'un dialecte serait le schéma de quelqu'un d'autre à maintenir en phase.
164
165| Reconnu | Comme |
166| --- | --- |
167| `# commentaire` | commentaire |
168| `clé:` avant un espace ou la fin de ligne | la clé comme identifiant, le deux-points comme ponctuation |
169| `"citée": 1`, `'citée': 1` | la clé citée comme identifiant |
170| `- ` ouvrant un élément de séquence | ponctuation |
171| `"…"`, `'…'` | chaîne |
172| `true`, `false`, `yes`, `no`, `on`, `off`, `null` | constante, quelle que soit la casse |
173| nombres, dates et heures écrits sans guillemets | nombre |
174| `&ancre`, `*alias` | builtin |
175| `!!str`, `!Custom` | type |
176| `---`, `...` | toute la ligne comme ponctuation |
177| `{`, `}`, `[`, `]`, `,` | ponctuation |
178| `\|`, `>`, avec leurs indicateurs de troncature et d'indentation | l'en-tête comme opérateur, le corps comme chaîne |
179
180**Un deux-points n'est un séparateur que si un espace ou la fin de ligne le suit.** `image: node:24-alpine` est une clé et une valeur, et `url: http://example.com/x` est une clé et une URL — colorer les deux-points intérieurs comme séparateurs mettrait chaque tag d'image et chaque URL en trois couleurs.
181
182**L'étendue d'un scalaire bloc est décidée par l'indentation**, pas par un délimiteur. La première ligne de contenu après `|` ou `>` fixe l'indentation du bloc ; chaque ligne indentée au moins autant lui appartient, et la première qui ne l'est pas le termine. **Une ligne vide dans un bloc reste dans le bloc** : un scalaire littéral garde ses lignes vides, et terminer le bloc au premier saut de paragraphe couperait en deux un script shell dans un fichier de CI.
183
184**Un `#` a besoin d'un espace devant pour ouvrir un commentaire**, `colour: ff#00aa` est donc un seul scalaire.
185
186| Non reconnu | Parce que |
187| --- | --- |
188| Le schéma d'un fichier compose, d'un manifeste ou d'un workflow | Colorer `services:` autrement que n'importe quelle clé signifie porter le schéma de quelqu'un d'autre, et il vieillit le jour où ils ajoutent une clé |
189| Les flux multi-documents comme documents séparés | `---` est coloré, mais rien n'est réinitialisé ; rien dans la coloration ne dépend des frontières de documents |
190| Si un mot nu est une chaîne ou un nombre pour un parseur | `1.2.3` est une version pour un lecteur et une chaîne pour YAML ; le scanner colore ce à quoi cela ressemble |
191
192## Markdown
193
194| Reconnu | Comme |
195| --- | --- |
196| `# Titre``###### Titre` | toute la ligne comme titre |
197| `**gras**`, `__gras__`, `*italique*`, `_italique_` | emphase |
198| `` `code` `` | chaîne |
199| `[texte](cible)`, `![alt](src)` | le tout comme lien |
200| `- `, `* `, `+ `, `1. `, `1) ` | le marqueur comme ponctuation |
201| `>` | ponctuation |
202| `---`, `***`, `___` | ponctuation |
203| les clôtures ` ``` ` et `~~~` | tout le bloc, lignes d'ouverture et de fermeture comprises, comme chaîne |
204
205Un bloc clôturé est **d'une seule couleur quel que soit le langage annoncé** : ```` ```javascript ```` ne colore pas son contenu comme du JavaScript dans un fichier Markdown. La suite de marqueurs qui ouvre un bloc doit être fermée par le même caractère, une clôture en accents graves n'est donc pas fermée par une en tildes. Une clôture non fermée colore jusqu'à la fin du fichier.
206
207La suite de marqueurs ouvrant une emphase doit être fermée par une suite de même longueur, `**gras**` est donc une portée plutôt que deux italiques.
208
209## HTML
210
211| Reconnu | Comme |
212| --- | --- |
213| `<tag`, `</tag`, `>`, `/>` | balise |
214| les noms d'attributs, dont `data-*`, `xlink:href`, `@click`, `v-bind.prop` | attribut |
215| `=` | opérateur |
216| `"…"`, `'…'` | chaîne |
217| `<!-- … -->`, sur plusieurs lignes | commentaire |
218| `&amp;`, `&#169;` | constante |
219| `<!DOCTYPE …>` et les autres déclarations | mot-clé |
220
221Le texte entre les balises n'est pas coloré. Un `&` nu sans `;` dans les 32 caractères est laissé tranquille, parce que c'est du texte légal.
222
223**Le contenu de `<script>` et `<style>` n'est pas coloré** comme du JavaScript et du CSS, même dans cet éditeur : le scanner HTML est celui de turbo-core, et il ne confie pas une région d'une ligne à un autre scanner.
224
225## XML
226
227Son propre scanner plutôt que celui de HTML, pour une raison qui compte : CDATA. Tout l'intérêt de `<![CDATA[ … ]]>` est que son contenu n'est *pas* du balisage, et colorer les balises qu'il contient comme des balises est exactement à l'envers.
228
229| Reconnu | Comme |
230| --- | --- |
231| `<?xml version="1.0"?>` et les autres instructions de traitement | la cible et `?>` comme mot-clé, les paires entre elles comme attributs et chaînes |
232| `<!DOCTYPE …>` et les autres formes `<!` | mot-clé |
233| `<!-- … -->`, sur plusieurs lignes | commentaire |
234| `<![CDATA[ … ]]>`, sur plusieurs lignes | chaîne |
235| `<tag`, `</tag`, `>`, `/>` | balise |
236| `<ns:tag>`, `xsi:type` | le préfixe et le nom local en **une** portée |
237| les noms d'attributs | attribut |
238| `=` | opérateur |
239| `"…"`, `'…'` | chaîne |
240| `&amp;`, `&#169;` | constante |
241
242**Un commentaire et une section CDATA se ferment sur des délimiteurs différents**, et sont portés séparément : un `-->` dans une section CDATA ne la termine pas.
243
244**Un `&` nu sans point-virgule dans les 32 caractères est laissé tranquille**, parce que c'est du texte légal dans bien des documents et qu'avaler le reste de la ligne serait la plus grosse erreur.
245
246Le texte entre les balises n'est pas coloré.
247
248## Shell
249
250Vaut pour `sh`, `bash` et `zsh` : les mots-clés reconnus sont ceux qu'ils partagent.
251
252| Reconnu | Comme |
253| --- | --- |
254| `if`, `then`, `fi`, `for`, `while`, `case`, `esac`, `function`, `return`, … | mot-clé |
255| `true`, `false` | constante |
256| `echo`, `printf`, `export`, `local`, `read`, `cd`, `set`, `source`, … | builtin |
257| `$NAME`, `${…}`, `$(…)`, `$1`, `$?`, `$@` | builtin |
258| le **premier mot nu d'une ligne** | fonction |
259| chaque mot nu suivant, et `NAME` dans `NAME=valeur` | identifiant |
260| `'…'`, sans rien d'échappé ni de développé dedans | chaîne |
261| `"…"`, avec les expansions dedans colorées comme des expansions | chaîne |
262| `#` jusqu'à la fin de ligne | commentaire |
263
264`$(a $(b) c)` est une seule portée : l'imbrication est comptée. Une option comme `-euo` est un seul mot, pas un moins et un mot.
265
266**Les heredocs ne sont pas reconnus.** `<<EOF` et le texte qui suit sont colorés comme du shell ordinaire.
267
268## Dockerfile
269
270| Reconnu | Comme |
271| --- | --- |
272| `FROM`, `RUN`, `COPY`, `ADD`, `ARG`, `ENV`, `CMD`, `ENTRYPOINT`, `EXPOSE`, `LABEL`, `USER`, `VOLUME`, `WORKDIR`, `HEALTHCHECK`, `ONBUILD`, `SHELL`, `STOPSIGNAL`, `MAINTAINER` | mot-clé, quelle que soit la casse |
273| `AS`, `NONE` | mot-clé |
274| `# commentaire`, y compris les directives `# syntax=` et `# escape=` | commentaire |
275| `--from=builder`, `--chown=me:me` | le nom de l'option comme attribut |
276| `$NAME`, `${NAME}`, `${NAME:-default}` | builtin, en une portée jusqu'à l'accolade fermante |
277| `"…"`, `'…'` | chaîne |
278| un `\` final | opérateur |
279| les nombres | nombre |
280| les chemins et références d'images — `/usr/local/bin`, `node:24-alpine` | identifiant, en **une** portée |
281
282**Seul le premier mot d'une ligne peut être une instruction**, et un mot qui n'en est pas une est un argument — ce qui garde le premier mot d'une ligne de continuation hors de la couleur des mots-clés.
283
284**Rien ne franchit une ligne.** Un `\` joint deux lignes pour Docker, mais chaque moitié se lit toujours comme une commande et est colorée seule.
285
286| Non reconnu | Parce que |
287| --- | --- |
288| Le shell dans un `RUN` | Il faudrait lancer le scanner shell sur une partie de ligne et reporter ses colonnes, et `RUN` peut contenir n'importe quel langage |
289| Les heredocs dans un `RUN` | La même raison que pour le scanner shell |
290| Quelle étape un `--from` nomme | Rien ici ne lit le reste du fichier |
291
292## Voir aussi
293
294- [Format des fichiers de thème](themes.md) — chaque clé vers laquelle ces classes résolvent
295- [Coloration et complétion](../explanation/colouring-and-completion.md) — pourquoi les scanners sont écrits ainsi
296- [Écrire son propre thème](../how-to/write-a-theme.md)