Evolution du markdown : conséquences

C'est dommage sur le principe, certes, mais ce n'est pas viable dans le court/moyen terme.

Seul un fonctionnement communautaire du process de validation pourrait permettre un niveau de validation aussi fin. On n'aura jamais le manpower suffisant pour assurer ça autrement.

Ok. Dommage, mais ok

Pour la validation, je laisse les valido en répondre.

EDIT : je pense à une autre chose. Est ce qu'il est possible de mettre dans le markdown des éléments spécifiques pour un format. Je pense par exemple à ajouter un saut de page qui ne serait pris en compte que dans la version pdf par exemple.

Autre exemple, dans le pdf de C++14, j'ai déplacé l'introduction "Le lundi 18 août, Herb Sutter1 a annoncé sur le site du comité…" dans le chapitre 1 "Un peu d'histoire", sinon on avait ce texte collé au sommaire, cela faisait étrange. Donc il faudrait pouvoir mettre ce texte au dessus du chapitre 1 dans le HTML et dans le chapitre 1 pour le PDF. (ou une autre solution)

C'est possible oui mais est ce souhaitable ? J'entends par là que tu va rajouter des balises pour gérer la mise en forme specifique, je préfère trouver une solution qui répond au problème réel.

Par exemple, si tu veux un saut de page pour être sûrs qu'un long bloc de code ne soit pas coupé en deux comme dans le template actuel alors la solution est plutôt de faire comme le template que j'ai actuellement en local et qui specifie qu'on veut éviter les coupures de pages dans les blocs de code.

Pour l'intro le prob est différent mais il est principalement dut au fait qu'on a actuellement un seul template, basé sur une class type book, et qui est adapté aux big tuto mais pas aux articles et mini tuto. Pour ces éléments je préfererai qu'on fasse deux templates, un pour les contenu long et un pour les contenu court (et se baser pour ce dernier sur une class article par ex).

(edit: et du coup tu place l'intro différement en fonction du type de contenu)

Concernant listing, je n'ai pas encore regardé a fond. Si la coloration n'est pas satisfaisante, on restera sur celle de Pandoc.

Merci a Kje pour ce gros récap. J'aurais quand même quelques remarques :

• Vu qu'on part sur du pandoc partout, est-ce qu'on a vérifié qu'on a pas de perte de perfs dans le parsing md -> html avec pandoc, part rapport à python-zmarkdown ? Y'a t-il moyen d'avoir un benchs pour avoir une idée ?
• Concernant le format d'export en html, les blocs de code ne sont pas un problème, on peut utiliser pygments là dessus non ? Sinon, on peut toujours envisager de faire de la coloration syntaxique en Javascript.
• Concernant l'export de format en PDF, Listing me semble être la bonne solution parmi celles évoquées dans ce topic. On aura certainement des langages non supportés au début, et je ne sais pas ce que ça représente en charge de travail de supporter un nouveau langage, mais je pense que c'est mieux d'avoir un code non coloré que d'avoir un code non wrappé dans un pdf.

Pour le coup, le sujet m'interesse, et je vais commencer à bricoler des trucs sur le fork.

Bench j'ai pas mais entre un vrai parseur compilé et un amoncellement de regexp en python, ça ne me fait pas trop peur.

Pour avoir une idée, prend Python-Markdown sans extension et pandoc en mode strict et mesure la différence de temps.

Pour la coloration du code en sortie HTML, on fait ce qu'on veut. Pygment, le truc intégré a pandoc ou autre chose.