Come on, Mark!

Ceux d'entre vous qui suivent l'actualité geek ont probablement entendu parler de Standard Markdown Common Markdown CommonMark, qui a l'ambition d'unifier et de standardiser Markdown.

Ceux qui me suivent depuis longtemps se souviennent peut-être de la catastrophe libupskirt, et pour les autres il suffit de savoir que j'ai écrit une bibliothèque C qui parse Markdown avec différents jeux d'extensions, et qui supporte différents formats de sortie. Il s'agit de libsoldout.

Même si libsoldout remplit parfaitement mes besoins, l'arrivée d'un format prétenduement unificateur pose la question de le supporter aussi, à côté.

Malheureusement, la réponse est que c'est la merde.

Les gens qui ont fait CommonMark avaient manifestement en tête une certaine architecture de parser, et ça a visiblement « fuit » dans la spécification du langage. Et évidemment, cette architecture n'est pas du tout la même que celle de libsoldout.

Pour faire simple, le cœur de libsoldout est un parser dit inline, c'est-à-dire qu'il considère l'entrée comme un flux infini de caractères qu'il traite petits bouts par petits bouts, voire caractère par caractère.

Ainsi, lorsque libsoldout rencontre un caractère actif, il détermine immédiatement son sens avant de traiter le suivant.

Par exemple, dans foo *bar baz* moo, lorsque la première étoile est rencontrée, il détermine immédiatement s'il s'agit d'une emphase valide, avant de s'occuper de l'intérieur.

Or dans l'exemple n°239 de la spécification, aux deux tiers du document, ils introduisent magiquement la notion de précédence entre les éléments span, de sorte que dans foo *bar `baz* moo`, la deuxième étoile doit faire partie du fragment de code délimité par `, plutôt que servir de fin à l'emphase.

À moins de faire des contorsions peu évidentes et fragiles, il n'est pas possible d'introduire une précédence dans ce type de parser, vu que le sort de chaque caractère doit être réglé avant de passer à la suite. Il faudrait décloisonner les éléments (i.e. que l'emphase soit capable de déterminer qu'un fragment de code lui boufferait son étoile), ou introduire la possibilité de défaire un élément (i.e. que la première étoile commence une tentative d'emphase, qui puisse éventuellement échouer si la suite ne lui fournit pas d'étoile finale comme dans cet exemple).

Évidemment, ce n'est qu'un exemple, mais CommonMark contient des tonnes de cas similaires : la précédence (encore une fois) des fenced code blocks sur les déclarations de références, certains échappements, etc.

Bref, malgré toute la flexibilité construite dans libsoldout, ajouter le support de CommonMark demanderait beaucoup d'efforts, peut-être plus qu'écrire un nouveau parser, pour un résultat plus fragile.

De plus, le gens de CommonMark fournissent généreusement une bibliothèque en C, alors que la raison d'être de libsoldout, c'était l'absence de bibliothèque dans un langage compilé. J'ai donc très envie d'envoyer les gens qui veulent du CommonMark vers l'implémentation officielle.

Une partie de moi me dit que c'est une mauvaise idée, parce que ça va marginaliser encore plus libsoldout, au point de lui faire perdre toute pertinence. Une autre me dit qu'elle est déjà au minimum et n'a plus rien à perdre.

Chers lecteurs, connaîtriez-vous des utilisateurs de libsoldout ? Que pensent-ils de CommonMark et d'un éventuel support dans libsoldout ?

Commentaires

1. Le mardi 11 novembre 2014 à 13:23, par nicoo :

ÀMA, la pertinence de `libsoldout` est aussi que l'utilisation de la mémoire est très prédictible (comme avec pas mal de parseurs inline); le hic, c'est que la spécification de CommonMark interdit ça, justement à cause des problèmes de précédence.

Du coup, nonobstant les problèmes de précédence, y a-t-il d'autres parties de la spec' que `libsoldout` viole ?
Y a-t-il des fonctionnalités qui ne sont pas implémentées ?

2. Le mardi 11 novembre 2014 à 15:59, par Natacha :

Si on suppose un document d'entrée écrit de telle sorte à ce que les histoires de précédence ne jouent pas, il me semble que libsoldout ne "viole" rien directement, mais il lui manque quelques fonctionnalités par rapport à CommonMark:

– les "fenced code blocks" (qui pourraient facilement être ajoutés) ;
— les emphases à base d'underscore qui ne sont reconnues qu'aux frontières des mots, contrairement aux étoiles qui sont reconnues à l'intérieur des mots (un peu pénible à implémenter proprement, mais tout à fait faisable) ;
– les listes plus subtiles : changer de liste quand on change de marqueur, tenir compte du numéro entré dans les listes ordonnées, etc (pénible à spécifier clairement par rapport à l'architecture actuelle, mais faisable, et ça devrait se laisser implémenter facilement une fois spécifié proprement) ;
– les références de lien qui sont insensibles à la casse en unicode (ce qui me semble insurmontable sans tirer une nouvelle (grosse ?) dépendance).

Je pense que ce ne sont que des petites choses, mais ça peut être rédhibitoire s'il faut gérer un corpus existant en CommonMark. Par contre pour des textes courts, comme un commentaire de blog, ça devrait être assez peu différent pour que la différence se fasse rarement sentir.

Poster un commentaire

Nom ou pseudonyme :

Adresse e-mail (facultatif, ne sera pas publié) :

Site web (facultatif) :

Format de mise en forme : format historique Markdown restreint

Enregistrer ces informations dans un cookie

Commentaire (sera publié dans cette page, voir les conseils de mise en forme ci-dessous) :

Message personnel (ne sera pas publié) :

Mise en forme historique : pour mettre en valeur un mot ou un groupe de mot, tapez une étoile de part et d'autre, sans mettre d'espace entre l'étoile et le mot, comme ceci : *mise en valeur*. Pour insérer un lien, mettez le entre crochets, comme ceci : [http://instinctive.eu/].

Mise en forme markdown : voir le guide détaillé, en résumé c'est le Markdown traditionnel, sans HTML ni titres, mais avec les tables PHP-Markdown-Extra.

Attention : les balises HTML entrées dans les commentaires seront affichées telles quelles, et non pas interprétées.