turbo-editors/turbo-rustpublic Fork 0
v1.0.1
Commits
Clone
git clone https://git.rickub.com/turbo-editors/turbo-rust.git
git clone ssh://git@rickub.com/turbo-editors/turbo-rust.git

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

📦 Turbo Rust 713ea5c · on v1.0.1 · k33g · 11h ago
languages.md · 283 lines · 16.9 KBmarkdown
Blame HistoryOpen raw

Référence : langages colorés

Description neutre des fichiers que Turbo Rust colore, de la façon dont il décide, et de ce que reconnaît chaque scanner.

Reconnaissance

L'extension d'un fichier décide dès qu'elle fait partie de celles-ci :

Extension Langage
.rs Rust
.toml TOML
.yaml, .yml YAML
.md, .markdown Markdown
.js, .mjs, .cjs JavaScript
.html, .htm HTML
.xml, .xsd, .xsl, .xslt, .svg, .plist, .csproj, .pom XML
.sh, .bash, .zsh Shell
.dockerfile, .containerfile Dockerfile

Les extensions sont comparées sans tenir compte de la casse, et seule la dernière compte : main.rs.backup n'est pas du Rust.

Un fichier dont l'extension ne décide de rien est ensuite cherché par son nom. Seuls les fichiers sans extension exploitable en ont besoin :

Nom Langage
Dockerfile, Containerfile Dockerfile

Un nom correspond sur sa totalité ou sur la partie précédant le premier point, sans tenir compte de la casse — ainsi Dockerfile, dockerfile et Dockerfile.dev sont tous reconnus, tandis que Dockerfile.md est du Markdown, puisque l'extension est consultée en premier.

Un fichier qu'aucun des deux tableaux ne revendique est un script shell si sa première ligne est un shebang nommant un shell — sh, bash, zsh, dash ou ksh, comme élément de chemin ou comme argument d'env. C'est ce qui colore configure, un hook git, ou un script que quelqu'un a renommé.

Première ligne Résultat
#!/bin/sh Shell
#!/usr/bin/env bash Shell
#!/usr/bin/env -S bash -e Shell
#!/usr/bin/env python3 Non coloré
Tout ce qui ne commence pas par #! Non coloré

L'ordre est fixe — extension, puis nom, puis première ligne — et le premier qui décide l'emporte : un fichier .rs commençant par un shebang reste du Rust.

Tout 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 simplement non coloré.

Classes

Tous les scanners produisent le même vocabulaire de classes, et chacune correspond à une clé de thème.

Classe Clé de thème Produite par
identifier syntax.identifier Rust, TOML, JavaScript, shell, YAML, Dockerfile
keyword syntax.keyword Rust, JavaScript, shell, HTML (doctype), XML, Dockerfile
type syntax.type Rust, TOML (en-têtes de table), YAML (étiquettes)
builtin syntax.builtin Rust, JavaScript, shell (builtins et expansions), YAML (ancres et alias), Dockerfile (variables)
constant syntax.constant Rust, TOML, JavaScript, shell, YAML, HTML et XML (entités)
function syntax.function Rust, JavaScript, shell (la commande)
string syntax.string tous
char syntax.char Rust
number syntax.number Rust, TOML, JavaScript, shell, YAML, Dockerfile
comment syntax.comment Rust, TOML, JavaScript, shell, HTML, YAML, XML, Dockerfile
operator syntax.operator Rust, TOML, JavaScript, shell, HTML, YAML (en-têtes de scalaire de bloc), XML, Dockerfile
punctuation syntax.punctuation Rust, TOML, JavaScript, shell, Markdown, YAML, Dockerfile
heading syntax.heading Markdown
tag syntax.tag HTML, XML
attribute syntax.attribute HTML, XML, Dockerfile (options)
emphasis syntax.emphasis Markdown
link syntax.link Markdown

Rust

Écrit à la main, dans internal/rustlang. Trois constructions traversent un saut de ligne et sont transportées exactement plutôt que devinées : un commentaire de bloc (avec sa profondeur d'imbrication), une chaîne brute (avec son nombre de dièses), et une chaîne ordinaire.

Reconnu Comme
fn, let, impl, struct, enum, trait, match, pub, mut, async, await, unsafe, … mot-clé
les mots réservés pour l'avenir — become, priv, typeof, unsized, … mot-clé
bool, char, str, i8i128, u8u128, isize, usize, f32, f64, self, Self type
tout autre nom commençant par une majuscule type
true, false, None, Some, Ok, Err constante
un nom immédiatement avant ( fonction
name!, le ! compris builtin
#[derive(Debug)], #![no_std] attribut
"…", b"…", sur plusieurs lignes, échappements honorés chaîne
r"…", r#"…"#, br##"…"##, sur plusieurs lignes chaîne
'x', '\n', '\u{1F600}', b'x' caractère
'a, 'static type
42, 1_000, 0xFF, 0b1010, 0o77, 1.5e-3, 42u8, 3.0f64 nombre
//, ///, //! jusqu'au bout de la ligne commentaire
/* … */, imbriqués, sur plusieurs lignes commentaire
.., ..= opérateur
:, :: ponctuation
suites de +-*/%=<>!&|^~? opérateur
()[]{},;. ponctuation

Une durée de vie se distingue d'un littéral de caractère en cherchant le guillemet fermant là où un caractère devrait le mettre — une rune plus loin, ou davantage pour un échappement. 'a est une durée de vie, 'a' un caractère, 'static une durée de vie, '\u{1F600}' un caractère. Se tromper là-dessus transforme le reste de la ligne en chaîne, d'où les tests dédiés.

Une durée de vie est colorée comme un type, parce que c'est un paramètre générique, déclaré et utilisé aux mêmes endroits qu'un type.

Une majuscule veut dire un type. La convention de nommage de Rust est assez forte pour qu'on s'y appuie : un type, un trait et une variante d'énumération sont tous en UpperCamelCase et rien d'autre ne l'est. Une constante en SCREAMING_SNAKE_CASE est colorée en type par cette règle, et c'est le seul endroit où l'heuristique se voit.

None, Some, Ok et Err appartiennent à Option et Result, pas au langage. Ils sont colorés en constantes parce qu'un lecteur les rencontre avant toute autre variante et les lit comme il lit true.

Les macros emportent leur !. println! est un seul segment ; a != b n'est pas une macro, et les deux se distinguent par le = qui suit.

Un nombre emporte son suffixe. 42u8 est un seul littéral, et colorer le u8 en type couperait en deux une chose qui n'en fait qu'une.

Un attribut qui dépasse la fin de sa ligne est coloré jusqu'au bout et n'est pas transporté. Contrairement à un commentaire ou une chaîne, un attribut non fermé est presque toujours un attribut à moitié tapé, et le transporter repeindrait le reste du fichier.

Non reconnu, chaque fois pour une raison donnée :

Non reconnu Parce que
Quelle macro est invoquée println! et une macro que vous avez écrite sont toutes deux des builtins ; les distinguer demande l'expansion de la caisse
L'intérieur d'un corps de macro Les corps de macro_rules! sont colorés comme du Rust ordinaire, ce qui est le plus souvent juste et parfois non
Les constantes en SCREAMING_SNAKE_CASE Indiscernables d'un nom de type par la règle de la majuscule, et une seconde règle mal-colorerait un type dont le nom est un acronyme
Le Markdown des commentaires de documentation Un commentaire /// est un commentaire, pas un document Markdown

TOML

Reconnu Comme
# commentaire comment
[table], [[array]] le nom en type, les crochets en punctuation
clé = identifier, puis operator
"basique", 'littérale', """multi-ligne""", '''multi-ligne''' string
true, false constant
nombres, dates, heures, inf, nan number

YAML

Un fichier compose, un manifeste Kubernetes et un workflow d'intégration continue 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.

Reconnu Comme
# commentaire commentaire
clé: suivie d'une espace ou de la fin de ligne la clé en identifiant, le deux-points en ponctuation
"entre guillemets": 1, 'apostrophes': 1 la clé citée en identifiant
- ouvrant une entrée de séquence ponctuation
"…", '…' chaîne
true, false, yes, no, on, off, null constante, quelle que soit la casse
nombres, dates et heures écrits sans guillemets nombre
&ancre, *alias builtin
!!str, !Custom type
---, ... toute la ligne en ponctuation
{, }, [, ], , ponctuation
|, >, avec leurs indicateurs de coupe et d'indentation l'en-tête en opérateur, le corps en chaîne

Un deux-points n'est un séparateur que si une espace ou la fin de ligne le suit. image: nginx:1.27 est une clé et une seule valeur, et url: http://example.com/x une clé et une seule URL — colorer les deux-points intérieurs en séparateurs mettrait chaque étiquette d'image et chaque URL en trois couleurs.

L'étendue d'un scalaire de 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 ; toute ligne indentée au moins autant lui appartient, et la première qui ne l'est pas y met fin. Une ligne vide à l'intérieur d'un bloc y reste : un scalaire littéral conserve ses lignes vides, et terminer le bloc au premier saut de paragraphe couperait en deux un script shell dans un fichier d'intégration continue.

Un # a besoin d'une espace devant lui pour ouvrir un commentaire, si bien que colour: ff#00aa est un seul scalaire.

Non reconnu Parce que
Le schéma d'un fichier compose, d'un manifeste ou d'un workflow Colorer services: autrement qu'une clé quelconque revient à transporter le schéma de quelqu'un d'autre, qui se périme le jour où il ajoute une clé
Les flux multi-documents comme documents distincts --- est coloré, mais rien n'est réinitialisé à cet endroit ; rien dans la coloration ne dépend des frontières de documents
Si un mot nu est une chaîne ou un nombre pour un analyseur 1.2.3 est une version pour un lecteur et une chaîne pour YAML ; l'analyseur colore ce à quoi cela ressemble

Markdown

Reconnu Comme
# Titre###### Titre toute la ligne en heading
**gras**, __gras__, *italique*, _italique_ emphasis
`code` string
[texte](cible), ![alt](src) l'ensemble en link
- , * , + , 1. , 1) le marqueur en punctuation
> punctuation
---, ***, ___ punctuation
clôtures ``` et ~~~ tout le bloc, lignes d'ouverture et de fermeture comprises, en string

Un bloc clôturé est d'une seule couleur quel que soit le langage annoncé : ```rust ne colore pas son contenu en Rust. La suite de marqueurs qui ouvre un bloc doit être fermée par le même caractère : une clôture en accents graves ne se ferme pas par des tildes. Une clôture non fermée colore jusqu'à la fin du fichier.

La suite de marqueurs qui ouvre une emphase doit être fermée par une suite de même longueur, de sorte que **gras** fasse un seul span et non deux italiques.

JavaScript

Reconnu Comme
const, let, function, class, async, await, import, export, … keyword
true, false, null, undefined, NaN, Infinity, this constant
console, document, window, Array, Object, Promise, Math, JSON, … builtin
un nom immédiatement suivi de ( function
"…", '…' string
`…`, interpolations comprises, sur plusieurs lignes string
// jusqu'à la fin de la ligne, /* … */ sur plusieurs lignes comment
42, 3.14, 0x1f, 0b1010, 0o777, 1_000_000, 1e6, 10n number
suites de `+-*/%=<>!& ^~?:`
()[]{},;. punctuation

Les littéraux d'expression régulière ne sont pas reconnus. Distinguer /x/g d'une division exige de savoir si le token précédent pouvait terminer une expression ; une mauvaise supposition colore le reste de la ligne comme une chaîne, ce qui est pire que de laisser une regex à la couleur d'un opérateur.

Les globales sont reconnues par leur nom : un fichier qui masque Math la voit quand même colorée comme un builtin — la même règle que les types primitifs de Rust.

HTML

Reconnu Comme
<balise, </balise, >, /> tag
noms d'attributs, dont data-*, xlink:href, @click, v-bind.prop attribute
= operator
"…", '…' string
<!-- … -->, sur plusieurs lignes comment
&amp;, &#169; constant
<!DOCTYPE …> et les autres déclarations keyword

Le texte entre balises n'est pas coloré. Une esperluette isolée sans ; dans les 32 caractères qui suivent est laissée telle quelle, parce que c'est du texte légal.

Le contenu de <script> et de <style> n'est pas coloré en JavaScript ni en CSS.

XML

Son propre analyseur plutôt que celui du 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'inverse.

Reconnu Comme
<?xml version="1.0"?> et les autres instructions de traitement la cible et ?> en mot-clé, les paires entre les deux en attributs et chaînes
<!DOCTYPE …> et les autres formes <! mot-clé
<!-- … -->, sur plusieurs lignes commentaire
<![CDATA[ … ]]>, sur plusieurs lignes chaîne
<balise, </balise, >, /> balise
<ns:balise>, xsi:type le préfixe et le nom local en un seul segment
les noms d'attributs attribut
= opérateur
"…", '…' chaîne
&amp;, &#169; constante

Un commentaire et une section CDATA se ferment sur des délimiteurs différents, et sont transportés séparément : un --> à l'intérieur d'une section CDATA n'y met pas fin.

Une esperluette isolée sans point-virgule dans les 32 caractères suivants est laissée telle quelle, 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.

Le texte entre balises n'est pas coloré.

Shell

S'applique indifféremment à sh, bash et zsh : les mots-clés reconnus sont ceux qu'ils partagent.

Reconnu Comme
if, then, fi, for, while, case, esac, function, return, … keyword
true, false constant
echo, printf, export, local, read, cd, set, source, … builtin
$NOM, ${…}, $(…), $1, $?, $@ builtin
le premier mot nu d'une ligne function
tout mot nu suivant, et NOM dans NOM=valeur identifier
'…', sans échappement ni expansion à l'intérieur string
"…", avec les expansions colorées comme telles string
# jusqu'à la fin de la ligne comment

$(a $(b) c) fait un seul span : l'imbrication est comptée. Une option comme -euo est un seul mot, et non un moins suivi d'un mot.

Les heredocs ne sont pas reconnus. <<EOF et le texte qui suit sont colorés comme du shell ordinaire.

Dockerfile

Reconnu Comme
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
AS, NONE mot-clé
# commentaire, y compris les directives # syntax= et # escape= commentaire
--from=builder, --chown=me:me le nom de l'option en attribut
$NOM, ${NOM}, ${NOM:-defaut} builtin, en un seul segment jusqu'à l'accolade fermante
"…", '…' chaîne
un \ final opérateur
les nombres nombre
chemins et références d'images — /usr/local/bin, golang:1.26-alpine identifiant, en un seul segment

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.

Rien ne traverse un saut de ligne. Un \ joint deux lignes pour Docker, mais chaque moitié se lit encore comme une commande et est colorée pour elle-même.

Non reconnu Parce que
Le shell à l'intérieur d'un RUN Il faudrait passer l'analyseur shell sur une partie de ligne et en remonter les colonnes, et un RUN peut contenir n'importe quel langage
Les heredocs dans un RUN La même raison que pour l'analyseur shell
Quelle étape nomme un --from Rien ici ne lit le reste du fichier

Voir aussi

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
# Référence : langages colorés

> Description neutre des fichiers que Turbo Rust colore, de la façon dont il décide, et de ce que reconnaît chaque scanner.

## Reconnaissance

L'**extension** d'un fichier décide dès qu'elle fait partie de celles-ci :

| Extension | Langage |
| --- | --- |
| `.rs` | Rust |
| `.toml` | TOML |
| `.yaml`, `.yml` | YAML |
| `.md`, `.markdown` | Markdown |
| `.js`, `.mjs`, `.cjs` | JavaScript |
| `.html`, `.htm` | HTML |
| `.xml`, `.xsd`, `.xsl`, `.xslt`, `.svg`, `.plist`, `.csproj`, `.pom` | XML |
| `.sh`, `.bash`, `.zsh` | Shell |
| `.dockerfile`, `.containerfile` | Dockerfile |

Les extensions sont comparées sans tenir compte de la casse, et seule la dernière compte : `main.rs.backup` n'est pas du Rust.

Un fichier dont l'extension ne décide de rien est ensuite cherché par son **nom**. Seuls les fichiers sans extension exploitable en ont besoin :

| Nom | Langage |
| --- | --- |
| `Dockerfile`, `Containerfile` | Dockerfile |

Un nom correspond sur sa totalité ou sur la partie précédant le premier point, sans tenir compte de la casse — ainsi `Dockerfile`, `dockerfile` et `Dockerfile.dev` sont tous reconnus, tandis que `Dockerfile.md` est du Markdown, puisque l'extension est consultée en premier.

Un fichier qu'aucun des deux tableaux ne revendique est un **script shell** si sa première ligne est un shebang nommant un shell — `sh`, `bash`, `zsh`, `dash` ou `ksh`, comme élément de chemin ou comme argument d'`env`. C'est ce qui colore `configure`, un hook git, ou un script que quelqu'un a renommé.

| Première ligne | Résultat |
| --- | --- |
| `#!/bin/sh` | Shell |
| `#!/usr/bin/env bash` | Shell |
| `#!/usr/bin/env -S bash -e` | Shell |
| `#!/usr/bin/env python3` | Non coloré |
| Tout ce qui ne commence pas par `#!` | Non coloré |

L'ordre est fixe — extension, puis nom, puis première ligne — et le premier qui décide l'emporte : un fichier `.rs` commençant par un shebang reste du Rust.

Tout 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 simplement non coloré.

## Classes

Tous les scanners produisent le même vocabulaire de classes, et chacune correspond à une clé de thème.

| Classe | Clé de thème | Produite par |
| --- | --- | --- |
| `identifier` | `syntax.identifier` | Rust, TOML, JavaScript, shell, YAML, Dockerfile |
| `keyword` | `syntax.keyword` | Rust, JavaScript, shell, HTML (doctype), XML, Dockerfile |
| `type` | `syntax.type` | Rust, TOML (en-têtes de table), YAML (étiquettes) |
| `builtin` | `syntax.builtin` | Rust, JavaScript, shell (builtins et expansions), YAML (ancres et alias), Dockerfile (variables) |
| `constant` | `syntax.constant` | Rust, TOML, JavaScript, shell, YAML, HTML et XML (entités) |
| `function` | `syntax.function` | Rust, JavaScript, shell (la commande) |
| `string` | `syntax.string` | tous |
| `char` | `syntax.char` | Rust |
| `number` | `syntax.number` | Rust, TOML, JavaScript, shell, YAML, Dockerfile |
| `comment` | `syntax.comment` | Rust, TOML, JavaScript, shell, HTML, YAML, XML, Dockerfile |
| `operator` | `syntax.operator` | Rust, TOML, JavaScript, shell, HTML, YAML (en-têtes de scalaire de bloc), XML, Dockerfile |
| `punctuation` | `syntax.punctuation` | Rust, TOML, JavaScript, shell, Markdown, YAML, Dockerfile |
| `heading` | `syntax.heading` | Markdown |
| `tag` | `syntax.tag` | HTML, XML |
| `attribute` | `syntax.attribute` | HTML, XML, Dockerfile (options) |
| `emphasis` | `syntax.emphasis` | Markdown |
| `link` | `syntax.link` | Markdown |

## Rust

Écrit à la main, dans `internal/rustlang`. Trois constructions traversent un saut de ligne et sont transportées exactement plutôt que devinées : un commentaire de bloc (avec sa profondeur d'imbrication), une chaîne brute (avec son nombre de dièses), et une chaîne ordinaire.

| Reconnu | Comme |
| --- | --- |
| `fn`, `let`, `impl`, `struct`, `enum`, `trait`, `match`, `pub`, `mut`, `async`, `await`, `unsafe`, … | mot-clé |
| les mots réservés pour l'avenir — `become`, `priv`, `typeof`, `unsized`, … | mot-clé |
| `bool`, `char`, `str`, `i8``i128`, `u8``u128`, `isize`, `usize`, `f32`, `f64`, `self`, `Self` | type |
| tout autre nom commençant par une majuscule | type |
| `true`, `false`, `None`, `Some`, `Ok`, `Err` | constante |
| un nom immédiatement avant `(` | fonction |
| `name!`, le `!` compris | builtin |
| `#[derive(Debug)]`, `#![no_std]` | attribut |
| `"…"`, `b"…"`, sur plusieurs lignes, échappements honorés | chaîne |
| `r"…"`, `r#"…"#`, `br##"…"##`, sur plusieurs lignes | chaîne |
| `'x'`, `'\n'`, `'\u{1F600}'`, `b'x'` | caractère |
| `'a`, `'static` | type |
| `42`, `1_000`, `0xFF`, `0b1010`, `0o77`, `1.5e-3`, `42u8`, `3.0f64` | nombre |
| `//`, `///`, `//!` jusqu'au bout de la ligne | commentaire |
| `/* … */`, **imbriqués**, sur plusieurs lignes | commentaire |
| `..`, `..=` | opérateur |
| `:`, `::` | ponctuation |
| suites de `+-*/%=<>!&\|^~?` | opérateur |
| `()[]{},;.` | ponctuation |

**Une durée de vie se distingue d'un littéral de caractère** en cherchant le guillemet fermant là où un caractère devrait le mettre — une rune plus loin, ou davantage pour un échappement. `'a` est une durée de vie, `'a'` un caractère, `'static` une durée de vie, `'\u{1F600}'` un caractère. Se tromper là-dessus transforme le reste de la ligne en chaîne, d'où les tests dédiés.

**Une durée de vie est colorée comme un type**, parce que c'est un paramètre générique, déclaré et utilisé aux mêmes endroits qu'un type.

**Une majuscule veut dire un type.** La convention de nommage de Rust est assez forte pour qu'on s'y appuie : un type, un trait et une variante d'énumération sont tous en `UpperCamelCase` et rien d'autre ne l'est. Une constante en `SCREAMING_SNAKE_CASE` est colorée en type par cette règle, et c'est le seul endroit où l'heuristique se voit.

**`None`, `Some`, `Ok` et `Err` appartiennent à Option et Result, pas au langage.** Ils sont colorés en constantes parce qu'un lecteur les rencontre avant toute autre variante et les lit comme il lit `true`.

**Les macros emportent leur `!`.** `println!` est un seul segment ; `a != b` n'est pas une macro, et les deux se distinguent par le `=` qui suit.

**Un nombre emporte son suffixe.** `42u8` est un seul littéral, et colorer le `u8` en type couperait en deux une chose qui n'en fait qu'une.

**Un attribut qui dépasse la fin de sa ligne est coloré jusqu'au bout et n'est pas transporté.** Contrairement à un commentaire ou une chaîne, un attribut non fermé est presque toujours un attribut à moitié tapé, et le transporter repeindrait le reste du fichier.

**Non reconnu**, chaque fois pour une raison donnée :

| Non reconnu | Parce que |
| --- | --- |
| Quelle macro est invoquée | `println!` et une macro que vous avez écrite sont toutes deux des builtins ; les distinguer demande l'expansion de la caisse |
| L'intérieur d'un corps de macro | Les corps de `macro_rules!` sont colorés comme du Rust ordinaire, ce qui est le plus souvent juste et parfois non |
| Les constantes en `SCREAMING_SNAKE_CASE` | Indiscernables d'un nom de type par la règle de la majuscule, et une seconde règle mal-colorerait un type dont le nom est un acronyme |
| Le Markdown des commentaires de documentation | Un commentaire `///` est un commentaire, pas un document Markdown |

## TOML

| Reconnu | Comme |
| --- | --- |
| `# commentaire` | comment |
| `[table]`, `[[array]]` | le nom en type, les crochets en punctuation |
| `clé =` | identifier, puis operator |
| `"basique"`, `'littérale'`, `"""multi-ligne"""`, `'''multi-ligne'''` | string |
| `true`, `false` | constant |
| nombres, dates, heures, `inf`, `nan` | number |

## YAML

Un fichier compose, un manifeste Kubernetes et un workflow d'intégration continue 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.

| Reconnu | Comme |
| --- | --- |
| `# commentaire` | commentaire |
| `clé:` suivie d'une espace ou de la fin de ligne | la clé en identifiant, le deux-points en ponctuation |
| `"entre guillemets": 1`, `'apostrophes': 1` | la clé citée en identifiant |
| `- ` ouvrant une entrée de séquence | ponctuation |
| `"…"`, `'…'` | chaîne |
| `true`, `false`, `yes`, `no`, `on`, `off`, `null` | constante, quelle que soit la casse |
| nombres, dates et heures écrits sans guillemets | nombre |
| `&ancre`, `*alias` | builtin |
| `!!str`, `!Custom` | type |
| `---`, `...` | toute la ligne en ponctuation |
| `{`, `}`, `[`, `]`, `,` | ponctuation |
| `\|`, `>`, avec leurs indicateurs de coupe et d'indentation | l'en-tête en opérateur, le corps en chaîne |

**Un deux-points n'est un séparateur que si une espace ou la fin de ligne le suit.** `image: nginx:1.27` est une clé et une seule valeur, et `url: http://example.com/x` une clé et une seule URL — colorer les deux-points intérieurs en séparateurs mettrait chaque étiquette d'image et chaque URL en trois couleurs.

**L'étendue d'un scalaire de 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 ; toute ligne indentée au moins autant lui appartient, et la première qui ne l'est pas y met fin. **Une ligne vide à l'intérieur d'un bloc y reste** : un scalaire littéral conserve ses lignes vides, et terminer le bloc au premier saut de paragraphe couperait en deux un script shell dans un fichier d'intégration continue.

**Un `#` a besoin d'une espace devant lui pour ouvrir un commentaire**, si bien que `colour: ff#00aa` est un seul scalaire.

| Non reconnu | Parce que |
| --- | --- |
| Le schéma d'un fichier compose, d'un manifeste ou d'un workflow | Colorer `services:` autrement qu'une clé quelconque revient à transporter le schéma de quelqu'un d'autre, qui se périme le jour où il ajoute une clé |
| Les flux multi-documents comme documents distincts | `---` est coloré, mais rien n'est réinitialisé à cet endroit ; rien dans la coloration ne dépend des frontières de documents |
| Si un mot nu est une chaîne ou un nombre pour un analyseur | `1.2.3` est une version pour un lecteur et une chaîne pour YAML ; l'analyseur colore ce à quoi cela ressemble |

## Markdown

| Reconnu | Comme |
| --- | --- |
| `# Titre``###### Titre` | toute la ligne en heading |
| `**gras**`, `__gras__`, `*italique*`, `_italique_` | emphasis |
| `` `code` `` | string |
| `[texte](cible)`, `![alt](src)` | l'ensemble en link |
| `- `, `* `, `+ `, `1. `, `1) ` | le marqueur en punctuation |
| `>` | punctuation |
| `---`, `***`, `___` | punctuation |
| clôtures ` ``` ` et `~~~` | tout le bloc, lignes d'ouverture et de fermeture comprises, en string |

Un bloc clôturé est **d'une seule couleur quel que soit le langage annoncé** : ```` ```rust ```` ne colore pas son contenu en Rust. La suite de marqueurs qui ouvre un bloc doit être fermée par le même caractère : une clôture en accents graves ne se ferme pas par des tildes. Une clôture non fermée colore jusqu'à la fin du fichier.

La suite de marqueurs qui ouvre une emphase doit être fermée par une suite de même longueur, de sorte que `**gras**` fasse un seul span et non deux italiques.

## JavaScript

| Reconnu | Comme |
| --- | --- |
| `const`, `let`, `function`, `class`, `async`, `await`, `import`, `export`, … | keyword |
| `true`, `false`, `null`, `undefined`, `NaN`, `Infinity`, `this` | constant |
| `console`, `document`, `window`, `Array`, `Object`, `Promise`, `Math`, `JSON`, … | builtin |
| un nom immédiatement suivi de `(` | function |
| `"…"`, `'…'` | string |
| `` `` ``, interpolations comprises, sur plusieurs lignes | string |
| `//` jusqu'à la fin de la ligne, `/* … */` sur plusieurs lignes | comment |
| `42`, `3.14`, `0x1f`, `0b1010`, `0o777`, `1_000_000`, `1e6`, `10n` | number |
| suites de `+-*/%=<>!&|^~?:` | operator |
| `()[]{},;.` | punctuation |

**Les littéraux d'expression régulière ne sont pas reconnus.** Distinguer `/x/g` d'une division exige de savoir si le token précédent pouvait terminer une expression ; une mauvaise supposition colore le reste de la ligne comme une chaîne, ce qui est pire que de laisser une regex à la couleur d'un opérateur.

Les globales sont reconnues par leur nom : un fichier qui masque `Math` la voit quand même colorée comme un builtin — la même règle que les types primitifs de Rust.

## HTML

| Reconnu | Comme |
| --- | --- |
| `<balise`, `</balise`, `>`, `/>` | tag |
| noms d'attributs, dont `data-*`, `xlink:href`, `@click`, `v-bind.prop` | attribute |
| `=` | operator |
| `"…"`, `'…'` | string |
| `<!-- … -->`, sur plusieurs lignes | comment |
| `&amp;`, `&#169;` | constant |
| `<!DOCTYPE …>` et les autres déclarations | keyword |

Le texte entre balises n'est pas coloré. Une esperluette isolée sans `;` dans les 32 caractères qui suivent est laissée telle quelle, parce que c'est du texte légal.

**Le contenu de `<script>` et de `<style>` n'est pas coloré** en JavaScript ni en CSS.

## XML

Son propre analyseur plutôt que celui du 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'inverse.

| Reconnu | Comme |
| --- | --- |
| `<?xml version="1.0"?>` et les autres instructions de traitement | la cible et `?>` en mot-clé, les paires entre les deux en attributs et chaînes |
| `<!DOCTYPE …>` et les autres formes `<!` | mot-clé |
| `<!-- … -->`, sur plusieurs lignes | commentaire |
| `<![CDATA[ … ]]>`, sur plusieurs lignes | chaîne |
| `<balise`, `</balise`, `>`, `/>` | balise |
| `<ns:balise>`, `xsi:type` | le préfixe et le nom local en **un seul** segment |
| les noms d'attributs | attribut |
| `=` | opérateur |
| `"…"`, `'…'` | chaîne |
| `&amp;`, `&#169;` | constante |

**Un commentaire et une section CDATA se ferment sur des délimiteurs différents**, et sont transportés séparément : un `-->` à l'intérieur d'une section CDATA n'y met pas fin.

**Une esperluette isolée sans point-virgule dans les 32 caractères suivants est laissée telle quelle**, 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.

Le texte entre balises n'est pas coloré.

## Shell

S'applique indifféremment à `sh`, `bash` et `zsh` : les mots-clés reconnus sont ceux qu'ils partagent.

| Reconnu | Comme |
| --- | --- |
| `if`, `then`, `fi`, `for`, `while`, `case`, `esac`, `function`, `return`, … | keyword |
| `true`, `false` | constant |
| `echo`, `printf`, `export`, `local`, `read`, `cd`, `set`, `source`, … | builtin |
| `$NOM`, `${…}`, `$(…)`, `$1`, `$?`, `$@` | builtin |
| le **premier mot nu d'une ligne** | function |
| tout mot nu suivant, et `NOM` dans `NOM=valeur` | identifier |
| `'…'`, sans échappement ni expansion à l'intérieur | string |
| `"…"`, avec les expansions colorées comme telles | string |
| `#` jusqu'à la fin de la ligne | comment |

`$(a $(b) c)` fait un seul span : l'imbrication est comptée. Une option comme `-euo` est un seul mot, et non un moins suivi d'un mot.

**Les heredocs ne sont pas reconnus.** `<<EOF` et le texte qui suit sont colorés comme du shell ordinaire.

## Dockerfile

| Reconnu | Comme |
| --- | --- |
| `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 |
| `AS`, `NONE` | mot-clé |
| `# commentaire`, y compris les directives `# syntax=` et `# escape=` | commentaire |
| `--from=builder`, `--chown=me:me` | le nom de l'option en attribut |
| `$NOM`, `${NOM}`, `${NOM:-defaut}` | builtin, en un seul segment jusqu'à l'accolade fermante |
| `"…"`, `'…'` | chaîne |
| un `\` final | opérateur |
| les nombres | nombre |
| chemins et références d'images — `/usr/local/bin`, `golang:1.26-alpine` | identifiant, en **un seul** segment |

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

**Rien ne traverse un saut de ligne.** Un `\` joint deux lignes pour Docker, mais chaque moitié se lit encore comme une commande et est colorée pour elle-même.

| Non reconnu | Parce que |
| --- | --- |
| Le shell à l'intérieur d'un `RUN` | Il faudrait passer l'analyseur shell sur une partie de ligne et en remonter les colonnes, et un `RUN` peut contenir n'importe quel langage |
| Les heredocs dans un `RUN` | La même raison que pour l'analyseur shell |
| Quelle étape nomme un `--from` | Rien ici ne lit le reste du fichier |

## Voir aussi

- [Format des fichiers de thème](themes.md) — toutes les clés vers lesquelles ces classes se résolvent
- [Coloration et complétion](../explanation/colouring-and-completion.md) — pourquoi les scanners sont écrits ainsi
- [Écrire son propre thème](../how-to/write-a-theme.md)