ZEP-05 : Refonte du traitement markdown pour l'export

Je suis tombé sur la chaîne d'un fan de Haskell qui explique quelques parties du code de Pandoc. Il a fait d'autres videos qui ont l'air super intéressantes mais qui ne nous intéressent pas ici.

La première video explique succinctement Pandoc en regardant la fonction qui parse les adresses mails, et la seconde regarde de façon un peu plus général, le parseur de Markdown, qui est exactement celui qui nous intéresse.

Voici donc les deux videos à regarder car j'ai trouvé ça vraiment bien fait et très intéressant :

Pas le temps de regarder, c'est dommage, ça a l'air d'être une super trouvaille.

Question : est-ce que quelqu'un se jette à l'eau et tente de bidouiller Pandoc, ou est-ce que je dois noter ça sur ma todo-list de septembre ?

Je ne sais pas trop encore quel sera mon temps libre en août et en septembre, mais j'aimerai bien participer en tout cas. Mais je n'ai pas trop envie de m'engager si j'ai pas le temps de bidouiller quoi que ce soit derrière.

Bon, je remonte un peu ce sujet. Le consensus semble être pour baser notre travail sur Pandoc. Ne serait il pas judicieux du coup de fermer cet Zep (puisque le choix technologique a été fait) et d'en faire une nouvelle pour organiser ce nouveau dev ?

Outre mon plan de migration prévu, il peut être rapidement nécessaire de forker le dpot github de Pandoc pour pouvoir travailler dessus. Une premiere étape serait alors d'ajouter un format d'entrée "markdown-zds" qui, a l'instar des différentes alternatives déjà présentes (strict, github, etc.) activerait/désactiverait les extensions qui nous vont (par exemple on bloque tout html/css, on a besoin des tableaux, etc.)

Pourquoi fermer? On la passe en mode "vote" puis après en mode dev.

Hum… Ce que je pensais par "fermer" c'était passer aux votes pour valider le choix de migrer vers Pandoc. Apres je proposais de fermer et rouvrir un sujet pour bien dissocier ce zep qui concernait le choix technologique et la discussion sur comment on s'organise pour la migration et les discussions techniques sur Pandoc.

Le process décrit dans la ZEP-01, c'est de résumer au propre en premier post le consensus qui a été atteint (et pourquoi on l'a choisi par rapport aux autres alternatives), avant de passer la révision en [validation].

Je plussoie explicitement, étant donné que je n'ai pas encore eu le temps de formuler mon avis là dessus (trop long, la flemme toussa).

Mais en résumé, étant donné qu'on est sur une ZEP qui traite plus de l'aspect technique que du fonctionnel, j'aurai bien aimé qu'on aient des infos sur les aspects perfs, et maintenabilité (au sens ressources de dev et complexité du code). Sur ce genre de specs (assez technique au final), j'ai tendance à préférer une approche POC, plutôt que de décider aujourd'hui des choix technologique et se rendre compte à la fin du dev qu'on a de gros porblèmes de perfs par exemple.

Pour les perfs il suffirait de prendre une conv équivalente md -> html pour Python-markdown et Pandoc pour voir les différences de traitements. Ça ne couvrirait pas nos extensions mais donnerais déjà une première grosse approximation. Mais je ne doute pas trop du résultat (Pandoc est compilé et Ghc est assez performant).

Pour les ressources de de dev, j'en avait parlé. Mais étant donné que actuellement on a juste un seul dev sur Python-ZMarkdown, si on arrive a une première version avec un Pandoc modifié c'est qu'on aura eu au moins autant de dev pour le créer. La maintenance ne sera alors pas forcément plus problématique qu'actuellement.

Enfin pour le POC j'ai déjà proposé 4-5 étapes permettant une transition plus douce qu'un basculement de l'un à l'autre.

Le process décrit dans la ZEP-01, c'est de résumer au propre en premier post le consensus qui a été atteint (et pourquoi on l'a choisi par rapport aux autres alternatives), avant de passer la révision en [validation].

Plusieurs question :

• Doit on organiser un vote formel ou la solution actuelle retenu doit etre prise "en l'absence d'avis contraire" ?
• Si un choix technique a été acté, est ce que les détails techniques d'implémentation doit être fait à la suite (dans ce zep) ou dans un autre zep dédié ?

Mais je ne doute pas trop du résultat (Pandoc est compilé et Ghc est assez performant).

Je n'ai pas encore lu tout ça dans le détails, mais si on veut passer une entrée zmarkdown a pandoc, et que celui-ci doit repasser par du LateX pour génerer du pdf, un des souci qui existe aujourd'hui est le fait que pandoc (ou texlive je sais pas) a besoin que toutes les images soient downloadés en local pour les utiliser. Il me semble que ce souci est corrigé dans les dernières versions de texlive (mais étant sur debian, on se traine des trucs ancestraux )

un des souci qui existe aujourd'hui est le fait que pandoc (ou texlive je sais pas) a besoin que toutes les images soient downloadés en local pour les utiliser

C'est lié a tex et en fait il existe probablement des extensions latex qui s'en charge pour toi. Pour autant, le seul truc qui est facile à faire pour étendre Pandoc ce sont des filtres de l'AST (que tu peux écrire facilement dans le langage que tu veux). Or ton problème est très facile a résoudre par un filtre : tu choppe toutes les balises images, tu dl l'image et tu change la source. C'est un des rare morceaux de tes scripts qu'il serait facile de faire actuellement proprement pour Pandoc.

Est ce que quelqu'un a commencé quelque chose ou pas sur Pandoc ?

En ce qui me concerne j'ai complètement oublié et je n'aurais pas le temps d'ici la fin de la semaine voir pas avant octobre.

Bon, j'ai lu un peu le code de pandoc sur leur Github et c'est codé plutôt pas mal. Même moi qui ne fait pas de Haskell j'arrive à m'y retrouver. Alors en gros, pour ZdS si je résume on a :

• Le code python du site qui crache un énorme fichier au format zmarkdown.
• Pandoc ne comprend que le markdown et pas le zmarkdown.

Pour faire comprendre à pandoc le zmarkdown il faudrait forker le projet, et le modifier. Mais quel est le delta entre les deux ? C'est là que ça devient simple. On a juste besoin de rajouter à pandoc le support de :

• citation sourcée : actuellement pandoc comprend les citations, mais il ne comprend pas les sources de citation. Il faut donc rajouter dans le writer Latex le support des citation. Il faudra surrement étendre Blockquote pour qu'il comprenne ce qu'est une citation.
• Les blocks customs (information, question, attention, erreur) : Idem ici, il faudra créer une sorte de BlockInfo, … et définir ses readers et writers.

Techniquement on a besoin que de ça à rajouter dans pandoc et on aura des super exports.

Alors des motivés pour nous pondre un échantillon ?

Techniquement on a besoin que de ça à rajouter dans pandoc et on aura des super exports.

Il y a aussi les vidéos, le support des smileys, les légendes de figure sous la forme "Figure:…", etc.

Il n'y a rien d'insurmontable mais la question est de savoir qui fait quoi. Je veux bien m'y coller, c'est pour ça que je posais la question si quelqu'un avait déjà fait quelque chose. Il me faut juste une réponse.

Il y a aussi les vidéos, le support des smileys, les légendes de figure sous la forme "Figure:…", etc.

Les smileys sont déjà gérées il me semble dans les pdf (faut que je check), mais pour le reste oui

Il me faut juste une réponse.

Visiblement personne ne s'y est attardé pour l'instant. Je pense que tu peux y aller si tu te sens l'envie.

Ok je ferais alors un plan de migration pour prévoir les étapes, suivre l'avancement et comme ça si quelqu'un veut m'aider…

@firm1: J'ai une question, est ce que tes filtres pré-pandoc actuels sont problématiques où ils peuvent attendre pour être corrigés. En effet il semblerait qu'ils peuvent presque tous être refait probablement en utilisant la sémantique des filtres de pandoc ce qui permettrait d'en avoir une implémentation propre. Si oui, je les transforme avant de m'attaquer au fork de Pandoc.

Sinon pour transformer Pandoc, il faut commencer par rajouter dans Pandoc une variante zds au markdown (il y a déjà des variantes pandoc, strict, github, etc…) qui se charge d'activer/désactiver les extensions disponibles dans Pandoc pour coller au plus pret de nos besoins. La suite va donc consister à mettre a jour toute la chaine. Je pense rechercher a obtenir une version a peu pret complète rapidement (ie: capable de parser l'entrée de manière complète), quitte a faire des transformations louche au début (ex: quand la balise touche est parsé, produire une AST de texte en gras+italique) pour rajouter le support complet au fur et a mesure (car a chaque ajout de sémantique il va y avoir minimum 3 générateurs a mettre a jour : latex, html et ebook. Ces deux derniers ne sont pas entièrement compatible car, par exemple, vous ne pouvez pas lire de vidéo sur un ebook bien que le gros du format est du html).

Des remarques/idées/commentaires ?

Je pense que c'est une évidence pour tout le monde, mais gérez un maximum de trucs dans le reader markdown de Pandoc. Typiquement, les smileys peuvent être remplacés par des images directement au moment du parsing. Idem pour les citations sourcées : l'AST de Pandoc gère des éléments inline à insérer avant et après la citation, il suffit donc de parser la source de la citation et d'introduire un élément inline du type "Source : " ++ contenu_source.

Pour les blocs personnalisés, je recommande de passer le plus possible par des blocs génériques de Pandoc. Ces blocs génériques sont grosso-modo équivalents à des div et des span en HTML. On peut ensuite les styliser avec le CSS (pour le HTML) ou en rajoutant des commandes dans le préambule (pour le LaTeX).

Avec tout ça, le seul truc qui nécessitera des modifications en profondeur de Pandoc est la balise vidéo. Mais déjà, un proof-of-concept qui gère “tout sauf la vidéo” est atteignable rapidement.

C'est pas si simple que ça. Par exemple une légende n'est pas un simple inline. En effet ils doivent être insérés avec des balisages dédié pour le html et latex. Par exemple, pour une citation en html, si il y a présence d'une source, l'élément blockquote doit être inséré dans un figure avec un figurecaption pour la légende. Et c'est a peu pret le même problème pour tout le reste.

Pour le reste, effectivement les div/span doit être utilisés, si possible.