Python-ZMarkdown

Est-ce que si on imagine un zmarkdown2, ce dernier doit etre ecrit en Python ?

S’il ne l’est pas, il faut au minimum un binding pour l’utiliser sur le site (afin de ne pas reproduire le problème actuel des parseurs différents pour les contenus et les messages du forum).

Non Saroupille, pas nécessairement. Et si on décide de partir en direction de commonmark, il me semble parfaitement envisageable de, si on prend l’exemple de la syntaxe des tableaux, faire zmarkdown-html -> commonmark. Donc déparser l’HTML des tableaux, ce qui semble moins pénible qu’écrite une conversion zmarkdown -> commonmark.

Je te laisse imaginer le temps que prendrait la conversion de l’ensemble des messages de ZdS à l’heure actuelle, et le bordel que ça serait de faire pareil au niveau des contenus (mon message, en substance disais ça).

On peut ne le faire qu’à la demande, quand un utilisateur veut éditer un contenu écrit avec une vieille version de Markdown.

Oui ça prendrait quelques minutes. Soyons le plus pessimiste possible, 1h de conversion qu’on peut tout à fait faire online.

Chui pas convaincu, mais pourquoi pas. Si quelqu’un est motivé …

Concrètement, en tant qu’auteur, ça ferait quel différence ? Parce que si j’en crois la page commonmark, seules nos extensions (bloc, exposant, barré, aligner au centre…) ne sont pas compatibles, puisque les syntaxes pour le reste semble OK. Je ne vois pas les transformations qu’il y aurait à faire.

jsfiddle?

Gabbro, en tant qu’auteur ça changerait presque rien. Il faudra peut-être garder l’aide-mémoire sous le coude au début, pour la syntaxe des tableaux par exemple, mais rien de compliqué.

Je me répète, mais les tableaux ne sont pas dans la spec.

Mais pierre_24 c’est quoi le rapport ? Je comprends de nouveau pas ton message.

Ben déjà parce que tu cause de tableau juste au dessus. Puis pour deux raisons:

• Ça veut dire qu’il faut aussi coder un plugin (et étendre l’AST) pour ça en plus du reste. Admettons que ce soit facile.
• Ça veut surtout dire que l’équipe derrière commonmark ne s’est pas encore mis d’accord sur la spécification des tableaux, ce qui veut dire que si ils finissent par ce mettre d’accord, ils peuvent très bien arriver à une solution qui n’est pas la notre, et donc on pourra recommencer le travail (à condition qu’on rebase sur leur upstream de manière régulière, bien entendu).

Au moins mdast avait les éléments définissant un tableau qui étaient déjà près, même si leur syntaxe n’est pas la notre (d’où mon blabla sur la conversion, j’essaye quand même d’être logique ).

À noter que toutes ces spécification semblent autoriser le HTML (ce qui permet aux gens de commonmark de ne jamais se mettre d’accord sur les tableaux, en soit, puisqu’il suffit de les faire en HTML, mais il faudrait en être sur¹). Je ne peux qu’émettre un énorme "non merci" à l’idée d’autoriser n’importe qui a mettre du HTML n’importe ou (bon, suffit de passer sur l’AST après et de supprimer les blocks en question, mais yeurk quand même).

Perso je pense qu’il faudrait partir sur un autre parseur en python, y rajouter nos extensions, et essayer de voir où il faut faire évoluer le parseur pour casser le moins de tests possible (car il y aura des incompatibilités quelque soit les éléments).

Une fois ça fait il sera toujours temps de mettre à jour le parseur pour faire plus.

Le python à un avantage en plus de bien s’intégrer au site : certaines extensions peuvent être reprises plus facilement. Typiquement quand j’ai réécrit l’extension des tableaux (probablement la plus chiante), en vrai on peut isoler facilement une fonction qui prend en entrée des lignes de textes et produits en sortie une pseudo astuces de tableau. Cette extension chiante est probablement assez facile à intégrer grâce au ménage que j’ai déjà fait.

Pour dire vrai j’ai sur mon pc un fork de la version Python de common mark. Pour le moment j’ai simplement commencé à la nettoyer pour le rendre plus pythonic (car c’est à la base une traduction de la version JS). L’objectif après était de rajouter les extensions. Ça me semblait une pas mauvaise idée. J’y touche de temps en temps mais pas assez à mon goût.

Ben déjà parce que tu cause de tableau juste au dessus.

Oui j’en parlais. Tu remarques que la discussion fait suite à l’annonce de la spec GFM :

Qui étend la spec commonmark avec notamment des tableaux, et étend l’implémentation de référence commonmark avec notamment des tableaux.

• Ça veut surtout dire que l’équipe derrière commonmark ne s’est pas encore mis d’accord sur la spécification des tableaux, ce qui veut dire que si ils finissent par ce mettre d’accord, ils peuvent très bien arriver à une solution qui n’est pas la notre, et donc on pourra recommencer le travail (à condition qu’on rebase sur leur upstream de manière régulière, bien entendu).

Je vois mal commonmark aller à l’encontre de GFM. Presque aucun risque.

Au moins mdast avait les éléments définissant un tableau qui étaient déjà près, même si leur syntaxe n’est pas la notre (d’où mon blabla sur la conversion, j’essaye quand même d’être logique ).

mdast décrit un AST, pas une syntaxe. Il n’y a pas une goutte de syntaxe dans mdast. Normal, c’est un AST. La syntaxe est abstraite, comme abstract syntax le suggère.

À noter que toutes ces spécification semblent autoriser le HTML (ce qui permet aux gens de commonmark de ne jamais se mettre d’accord sur les tableaux, en soit, puisqu’il suffit de les faire en HTML, mais il faudrait en être sur[^1]). Je ne peux qu’émettre un énorme "non merci" à l’idée d’autoriser n’importe qui a mettre du HTML n’importe ou (bon, suffit de passer sur l’AST après et de supprimer les blocks en question, mais yeurk quand même).

A nouveau, cette discussion part de la spec GFM. Donc cet argument ne tient pas non plus.

À titre perso, et en première étape, il nous faudrait un parseur qui comprend une grosse partie de notre syntaxe et produise une ast. Ça permettrait d’envisager de la changer plus sereinement. Changer la syntaxe on pourrait en parler en v2 mais pour moi c’est pas l’urgence.

Je suis bien d’accord Kje. A vue de pif, quantitativement, au moins 90% des éléments de syntaxe utilisés sur ZdS viennent directement du Markdown originel. Commonmark les comprend entièrement.

ZdS apporte pas mal de nouveaux trucs bizarres, mais très peu utilisés. Le gros est là, et le gros est du Markdown pur souche qui est compatible avec n’importe quel moteur Markdown, que celui-ci adhère à GFM, à Commonmark, au Markdown originel, ou autre.

Je comprends pas l’acharnement à dire que la situation actuelle est loin d’être idéale mais qu’on ne peut rien y faire, c’est comme ça, ne tentons rien.

Je viens de regarder mdast, l’idée est bonne mais je vois rien pour en faire quelque chose. On peut l’utiliser comme format interne mais ça ne semble pas pouvoir nous faire gagner du temps.

Bah, l’idée de mdast c’est de formaliser les éléments nécessaires à encoder dans un AST Markdown.

Je viens de prendre 10min pour torcher un truc. Le seul fichier qui contient vraiment un truc c’est ça : https://github.com/vhf/zmarkdown/blob/master/index.js

Ça tourne super lentement parce que hiff, pour pouvoir fournir un excellent diff html, est très lent. Si c’est juste remark qui passe sur nos tests et en fait de l’html, il va certainement pas mal plus vite que python.

 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

~/repos/zmarkdown/zmarkdown master
❯ node index.js
python-zmarkdown/tests/basic/amps-and-angle-encoding.txt failed
python-zmarkdown/tests/basic/angle-links-and-img.txt failed
python-zmarkdown/tests/basic/auto-links.txt success
python-zmarkdown/tests/basic/backlash-escapes.txt success
python-zmarkdown/tests/basic/blockquotes-with-code-blocks.txt success
python-zmarkdown/tests/basic/codeblock-in-list.txt success
python-zmarkdown/tests/basic/hard-wrapped.txt failed
python-zmarkdown/tests/basic/horizontal-rules.txt success
python-zmarkdown/tests/basic/inline-html-advanced.txt failed
python-zmarkdown/tests/basic/inline-html-comments.txt failed
python-zmarkdown/tests/basic/inline-html-simple.txt failed
python-zmarkdown/tests/basic/links-inline.txt failed
python-zmarkdown/tests/basic/links-reference.txt failed
python-zmarkdown/tests/basic/literal-quotes.txt failed
python-zmarkdown/tests/basic/markdown-documentation-basics.txt failed
python-zmarkdown/tests/basic/markdown-syntax.txt failed
python-zmarkdown/tests/basic/nested-blockquotes.txt success
python-zmarkdown/tests/basic/ordered-and-unordered-list.txt failed
python-zmarkdown/tests/basic/strong-and-em-together.txt success
python-zmarkdown/tests/basic/tabs.txt success
python-zmarkdown/tests/basic/tidyness.txt success
python-zmarkdown/tests/extensions/codehilite.txt failed
python-zmarkdown/tests/extensions/extra/abbr.txt failed
python-zmarkdown/tests/extensions/extra/extra_config.txt failed
…

En gros, si ça permet d’avoir un truc propre en peu de temps, un microservice qui s’occupe du rendu est une idée envisageable.

Si vous voulez voir à quoi ressemble un plugin remark, voici un exemple : https://github.com/ben-eb/remark-autolink-headings/blob/master/src/index.js

Perso j’ai rien contre faire le parseur en JS, bien au contraire, mais je sais pas si j’aurai le courage de m’en occuper.

Tant qu’on peut l’appeler pour qu’il s’occupe des contenus, peu importe le langage.