Journal écriture d'un script AWK de transformation de Markdown en HTML

Bonjour nal,

Ceci est un retour d'expérience sur l'écriture d'un script AWK de transformation de Markdown en HTML.

Ce script n'a pas vocation à être utilisé. Il y a déjà des outils mûres pour faire la même chose, en mieux.

Ce script est avant tout une expérimentation pour savoir si cela est faisable.

L'expérimentation est plutôt concluante puisqu'en quelques 80 lignes et un après midi de taf, le script couvre l'essentiel de Markdown :

• en-tête de chapitre #
• bloc de code et code intégré `
• images et liens [text](url)
• styles gras, barré et italique **bold**
• listes non ordonnées/ordonnées/imbriquées * foo
• listes de tâches - [ ] make journal
• tableaux |a|b|
• citation >
• ligne horizontale ---

Mais il n'est pas réellement robuste. Si le Markdown est volontairement alambiqué, le résultat n'est pas garanti.

Markdown

Markdown est omniprésent, dans les CMS (comme ce site), les forums (discourse), les chats (matrix), les forges (Gitea), les générateurs de sites statiques, les LLM. Bref, à peu près tout ce qui doit gérer du contenu texte.

Ce qui rend le concept puissant c'est que, par opposition au "markup", la syntaxe n'est pas contraignante. Ainsi, tout texte brut est aussi du Markdown et c'est à l'outil de tenté de faire un habillage.

Alors bien sûr si on écrit n'importe quoi, le résultat ne sera pas très beau, mais au moins on aura pas un "parsing error". On aura le texte brut, mais on ne perd pas de texte.

Étonnamment, Markdown n'est pas supporté nativement par les navigateurs web. Pour pallier ce manque, il existe une foultitude de programmes transformant du Markdown en HTML, dans tous les langages imaginables. Pourquoi pas en AWK.

AWK

Lorsque l'on développe en AWK, il faut avoir quelques principes en tête :

• AWK traite l'input une ligne après l'autre.
• Une ligne d'input est présente dans le contexte du programme sous sa forme entière (variable $0) et des champs qui la compose lorsqu'elle est découpé par un séparateur (variables $1 .. $NF).
• Lorsqu'il traite une ligne, AWK applique le script un bloc après l'autre, dans l'ordre.
• Chaque bloc de script est composé d'une condition et d'un bloc actions.
• Si la ligne d'input courante remplit la condition, les actions sont exécutées.
• Il est possible de mettre fin au script pour la ligne d'input courante et de passer à la ligne d'input suivante avec le mot clé next ; les blocs suivants ne sont pas exécutés.

Et ainsi appliquer les recettes suivantes:

• organiser le code pour avoir les traitements prioritaires en haut.
• au besoin, garder un état d'une ligne d'input à la suivante en utilisant des variables. Dans ce cas, il faut bien s'assurer de réinitialiser l'état le cas échéant
• au besoin, utiliser les tableaux associatifs pour stocker des états plus complexe, type hiérarchie

md2html.awk

Le script est organisé comme ceci:

• on traite d'abord tout ce qui ne doit pas subir de style, et en particulier les blocks de code ; et on stop le traitement
• on applique les styles ; et on continue le traitement
• on applique les liens et images ; et on continue le traitement
• on applique les en-tête de chapitre ; on stop
• on applique les traitements lorsqu'on est à l'intérieur d'un tableau ; on stop
  • on utilise ici une variable pour stocker le numéro de ligne dans le tableau
• on applique les traitements lorsqu'on est à l'intérieur d'une liste ; on stop
  • on utilise ici un tableau associatif pour stocker la hiérarchie de listes imbriquées
• si l'on est pas rentré dans le cas tableau ou liste, on est donc sorti de ce cas, on réinitialise leur état
• le cas par défaut est d'être dans un bloc de texte

Travaux antérieurs

J'ai voulu dans un premier temps produire le code "en chambre" afin de ne pas être influencé. Ensuite j'ai regardé ce qui avait déjà été fait. Il y a quelques pépites, surtout celles implémentant une machine à état, qui doivent être bien plus robustes que mon implémentation, mais aussi bien plus complexes.

Conclusion

J'aime beaucoup AWK et je crois savoir pourquoi : il y a une grande quantité de problèmes de traitement de données qui peuvent être résolus de manière locale (en flux), sans nécessité de traiter le document au global. Et cela conduit à des solutions très élégantes à mon goût.

---

Je ne sais pas si ce type de journal vous intéresse mais moi j'aimerai bien lire plus d'histoires de développeurs.