Tuto -> md : les dollars ne se sont pas échappés

[firm1]

Nos fichiers .tuto on été parsés en markdown. Mais il y'a encore quelques défauts qui trainent. Le dollars étant un caractères réservé, il doit dans n'importe quel texte être échappé. Quand ce n'est pas fait, la conversion en pdf nous crache au visage.

Je m'en suis rendu compte en travaillant avec le tuto linux de mateo. dans ce chapitre, on retrouve le caractère $ qui n'est pas précédé d'un \. Ce n'est pas normal.

Il y'en a pas des masses dans le tuto suscité, mais il suffit d'une erreur pour que la conversion ne passe pas.

@Coy0te qui s'en était occupé a t-il des infos sur le sujet ?

[Coy0te]

Ça n'était pas dans mon cahier des charges, je n'ai pas échappé les dollars dans la conversion.

On avait déjà remarqué le souci sur certains posts du forum quand on testait le md, ça vient de l'extension mathjax qui cherche à interpréter ce qui se trouve entre deux caractères dollar présents sur la même ligne.

On avait considéré dans je ne sais plus quelle issue que le cas où un type mettrait deux symboles dollars dans une même ligne/phrase était marginal dans un tuto, et que comme on ne récupère aucun tuto de finance, a priori ça ne vallait pas le coup de s'emmerder à parser ça.

Donc à moins qu'il y ait vraiment beaucoup de tutos dans lesquels le symbole dollar apparaît en dehors des balises de code, je pense qu'on peut partir sur des corrections marginales, à la main.

Par exemple dans ton lien, il m'a suffi de sauter une ligne pour la sous-puce pour corriger le pb (saut de ligne qui aurait d'ailleurs dû être là d'office, je trouve étrange qu'il ait sauté... faudra que je vérifie les sous-puces dans d'autres tutos pour voir).

---

De la même manière, j'en profite pour rappeler qu'il y a plusieurs dizaines de tutos dans lesquels il y a des tableaux en zCode, non convertis. La raison est qu'il ne sont pas valables d'un point de vue construction (je ne sais pas comment le zCode arrivait à bien les afficher sur la v3, et je ne veux pas le savoir!). Il faudra les corriger à la main. Exemple : un tableau de 5 colonnes de large, dont une des lignes ne comporte que 2 cellules simples + une autre avec colspan de 2 (pour un total de 4, inférieur à 5 donc).

[firm1]

On avait déjà remarqué le souci sur certains posts du forum quand on testait le md.

Concernant les posts du forum, on avait décidé il me semble de demander au personnes d'echapper eux même les dollars. Mais pour les tutos à importer, c'est vraiment compliquer de le faire manuellement, donc le mieux serait de les échapper en amont.

Tu penses pouvoir le faire ?

Par exemple dans ton lien, il m'a suffi de sauter une ligne pour la sous-puce pour corriger le pb

En fait le problème n'est pas corrigé. Le problème est que lors de l'export en pdf, pandoc te crachera à la gueule que ton fichier est mal constitué et ne générera aucun pdf (après pour savoir ou se trouve le problème c'est vraiment difficile), donc si on peut limiter la casse ...

De la même manière, j'en profite pour rappeler qu'il y a plusieurs dizaines de tutos dans lesquels il y a des tableaux en zCode, non convertis. La raison est qu'il ne sont pas valables d'un point de vue construction

Dans ce cas, il faudrait les lister ces tutos, et que quelqu'un (ou l'auteur) s'occupe de faire la maj manuelle.

[Coy0te]

J'ai la liste des tableaux foireux (ou tout du moins je peux la sortir, si tant est qu'on ait encore les versions d'origine des tutos à disposition).

Pour les corrections de ces tableaux, je pensais les faire moi-même dans tous les cours problématiques via l'éditeur de ZdS, mais vu qu'il a été décidé de ne pas importer automatiquement tous les cours, je ne l'ai pas fait (je n'ai pas voulu le faire à la main dans les fichiers .md, parce que la syntaxe des tableaux étant bien casse-couilles, un aperçu de ce que ça donne en HTML c'est pas de trop).

---

Pour le coup des dollars, ça ne m'enchante pas de les échapper automatiquement, pour deux raisons :

• ce n'est pas possible simplement via regex, parce qu'il ne faut pas échapper les dollar contenus dans des zones de code ;
• pour des raisons techniques, le premier traitement que j'applique c'est la transformation des balises de maths, c'est-à-dire la conversion de <math> vers le symboles... $. Impossible ensuite de savoir quel symbole $ est un symbole d'origine, ou une balise de math md. Donc impossible d'adapter mon parseur sans devoir me retaper des tests (manuels) de non régression longs comme un jour sans pain.

Bref, si on veut le faire de manière automatique, il faut créer un mini-parseur qui serait appliqué AVANT le mien, et dont le seul but serait d'échapper les dollars, en faisant gaffe de ne pas échapper ceux qui sont dans des balises code ou minicode.

Encore une fois, je pense que c'est un cas qui n'arrive pas souvent. Si les tutos sont bien rédigés, tous les dollars en rapports avec des noms de variable (PHP....) ou autres sont censés être dans des balises de code. Ça devrait être marginal de retrouver du dollar en dehors de ça.

P.S : le type qu'a décidé que le "standard" serait d'utiliser un unique symbole $ comme délimiteur pour les formules de maths, il devait quand même pas être hyper-brainy. C'est complètement pas intuitif de devoir échapper un dollar dans un post comme dans un tuto. C'est pourtant pas les symboles à la con où les dédoublements de symboles qui manquent, rien que $$ aurait réduit le risque de faux positif à presque zéro, et aurait permis de ne pas avoir à échapper le simple dollar.

[Edit] D'ailleurs, quand je vois ça je me dis qu'on a sûrement fait une connerie de garder cette notation avec les simples dollars. C'était Latex qui nous force à devoir utiliser ça ?

[cgabard]

Non on peut faire ce qu'on veut a condition de régler mathjax et le parseur markdown comme il faut.

Mais pour que ça marche correctement, il nous faut deux symboles distincts : un pour les formules inlines et un pour les formules indépendantes à centrer (surtout a cause de mathjax).

Donc je veux bien tout mettre a jour mais il faudrait se mettre d'accord sur les éléments à changer.

Cependant ça va aussi necessiter a firm1 de mettre a jour le script de preparation du markdown pour pandoc car lui utilise cette notation il me semble

[firm1]

Le contexte dans lequel on est est le suivant :

• mathjax utilise le simple dollar pour interpréter latex inline
• pandoc utilise le simple dollar pour transformer du un texte markdown vers un autre format.

Avec les technos en notre possession, je trouve ça plus efficace et moins chiants d'échapper les dollars des .tuto en sachant qu'on l'imposera aux auteurs par la suite, plutôt que de devoir modifier le comportement de mathjax (même si c'est simple a configurer) et réecrire un parseur (qui ne sera pas forcément efficace) pour pandoc.

Bref, si on veut le faire de manière automatique, il faut créer un mini-parseur qui serait appliqué AVANT le mien, et dont le seul but serait d'échapper les dollars, en faisant gaffe de ne pas échapper ceux qui sont dans des balises code ou minicode.

C'est bien a cette solution que je pensais, qui devrait être la moins coûteuse en temps et en energie pour tout le monde.

Encore une fois, je pense que c'est un cas qui n'arrive pas souvent.

On est d'accord, mais disons que quand ça arrive, et que ça fait planter un export de document, on ne sait pas forcément quel en est la cause précise.

Après, si vous voulez qu'on reparte sur d'autres symboles, ce n'est pas forcément trop tard, mais faut se décider vite.

[Coy0te]

C'est bien a cette solution que je pensais, qui devrait être la moins coûteuse en temps et en energie pour tout le monde.

Je vais faire une petite analyse de la situation ce midi sur les fichiers tutos.

[Coy0te]

Du coup tant qu'on y est, y'a d'autres symboles à la con qui font planter un export, ou juste le dollar ? J'ai cru lire un truc au sujet du symbole ~ dans je ne sais plus quelle doc.

[firm1]

Du coup tant qu'on y est, y'a d'autres symboles à la con qui font planter un export, ou juste le dollar ?

Pour le moment j'ai déniché la chaine \n, qui, lorsqu'elle est dans un texte hors du code, fait planter l'export pdf. Pour résoudre le problème j'ai du echapper le caractère, c'est à dire remplacer par \\n

Ceci dit, je me demande s'il ne faut pas traiter ce cas avant l'export. Car interdire le \n me parait gros quand même. Je vais voir ce que je peux faire en terme de regxp sur le sujet. Mais ce n'est pas trop mon fort. S'il y'a une lumière dans la salle ...

[Coy0te]

Je dois être rouillé, j'arrive pas à pondre un chiffre pertinent. J'ai tout juste réussi à appliquer un pauvre find . -name "*.xml" -exec grep -il "\\$" {} + | wc -l sur le dossier /Sources, et ça me dit qu'il y a... 327 tutos qui contiennent au moins un dollar.

Est que c'est possible avec une regex ou autre one-liner (ou presque) de compter les dollars qui sont contenus dans un fichier MAIS pas entre deux balises de code ou de minicode ? :-/

[Coy0te]

J'ai fini par trouvé un truc qui me semble (a priori) correct : => http://regexr.com/38pca

Regex : (?!<(code|minicode)[^>]*>)(\$)(?![^<]*<\/(code|minicode)>)

[Coy0te]

La regex ayant l'air de bien marcher, j'ai essayé de l'appliquer dans la commande grep suscitée, mais ça merde...

Quelqu'un sait faire fonctionner une telle regex dans grep (ou équivalent) ?

Perso je suis en vacances du 1 au 7 mai, (presque) pas d'internet à disposition. Si c'est pas fait à mon retour, je re-téléchargerai les sources au format zCode et le ferai directement via mon parseur Java.

[Coy0te]

A priori, le bug est toujours d'actualité, je vais tâcher de m'en occuper ce week-end.

Du coup, faudra pas oublier de regénérer les archives et renvoyer les liens aux auteurs, une fois que j'aurais reparsé et ré-uploadé les tutos convertis.

[cgabard]

On a désactivé les sauts de lignes qui générait les <br>, je ne sais pas si tu as un truc lié à ça, mais si oui, prend le en compte :)

[Coy0te]

Ah, j'ai pas regardé ça : un exemple avant/après pour que je pige bien de quoi il s'agit ?

[cgabard]

Avant, un paragraphe comme ça :

blab bla
tata toto

produisait, comme sur GitHub :

<p>blab bla<br/>tata toto</p>

alors que maintenant on est revenu au fonctionnement de markdown classique, ça produit :

<p>blab bla tata toto</p>

(le saut de ligne est un espace). Je ne sais pas si dans le zcode il y avait cette notion de saut de ligne qui intervenait.

Il est toujours possible de générer un saut de ligne (<br />) en rajoutant 2 espaces ou plus à la fin d'une ligne.

[Coy0te]

Ah ouais, d'accord.

Alors en ce qui concerne les cours au format zCode, ils en sont bourrés, de ces sauts de lignes uniques. Et oui, sur le SdZ, un saut de ligne produisait bien un saut de ligne. Ça nous promet de jolis pavés en sortie de conversion.... Perso je n'analyserai pas les sauts de lignes dans le parseur zCode -> md, les auteurs se débrouilleront.

Btw, my 2 cents : je ne sais pas bien pourquoi il a été décidé de ne pas utiliser la syntaxe github-flavored ici, et je me doute que vous deviez avoir vos raisons, mais je trouve ça contre-intuitif de devoir taper deux espaces à la fin d'une ligne pour produire un saut de ligne, je ne parle même pas du fait de ne pas produire de saut de ligne quand... on saute une ligne.

[SpaceFox]

Alors en ce qui concerne les cours au format zCode, ils en sont bourrés, de ces sauts de lignes uniques.

Sachant qu'en rédaction, on avait "un saut de ligne entré = un saut de ligne affiché", est-ce qu'il ne suffirait pas de remplacer "un saut de ligne" dans le tuto d'origine (je sais pas comment c'est matérialisé) par 2 sauts de lignes dans le Markdown produit, ce qui va bien nous générer un nouveau paragraphe ?

Btw, my 2 cents : je ne sais pas bien pourquoi il a été décidé de ne pas utiliser la syntaxe github-flavored ici, et je me doute que vous deviez avoir vos raisons, mais je trouve ça contre-intuitif de devoir taper deux espaces à la fin d'une ligne pour produire un saut de ligne, je ne parle même pas du fait de ne pas produire de saut de ligne quand... on saute une ligne.

Toute la discussion est là : http://zestedesavoir.com/forums/sujet/30/bug-reporte-md-les-sauts-de-ligne-intra-paragraphe TL;DR : c'est pour respecter le standard Markdown et donc l'interopérabilité avec les autres outils qui utilisent ce langage (dans la mesure du possible).

Le 9 mai 2014 14:14, Coyote notifications@github.com a écrit :

Ah ouais, d'accord.

Alors en ce qui concerne les cours au format zCode, ils en sont bourrés, de ces sauts de lignes uniques. Ça nous promet de jolis pavés en sortie de conversion.... Perso je ne m'amuserai pas à analyser les sauts de lignes dans le parseur zCode -> md, les auteurs se débrouilleront.

Btw, my 2 cents : je ne sais pas bien pourquoi il a été décidé de ne pas utiliser la syntaxe github-flavored ici, et je me doute que vous deviez avoir vos raisons, mais je trouve ça contre-intuitif de devoir taper deux espaces à la fin d'une ligne pour produire un saut de ligne, je ne parle même pas du fait de ne pas produire de saut de ligne quand... on saute une ligne.

— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/337#issuecomment-42659436 .

[firm1]

Perso je n'analyserai pas les sauts de lignes dans le parseur zCode -> md, les auteurs se débrouilleront.

Hm, c'est pas très gentil pour eux.

Je pense que si on veut attirer le maximum d'auteurs, il vaut mieux leur faciliter l'import des tutos plutôt que leur dire "démerdez vous".

[Coy0te]

Hm, c'est pas très gentil pour eux.

Qu'il n'y ait pas de malentendus : même si personnellement je trouve cette décision plutôt mauvaise, si je dis que je n'analyserai pas les sauts de ligne, ce n'est pas parce que je n'ai pas envie de le faire, mais simplement parce qu'à vue de pieds, ce n'est pas faisable de manière efficace (si tant est que ça soit faisable).

Il faudrait que je double les sauts de lignes présents dans du texte brut, ceux dans les balises inline (gras, etc.), ceux dans les balises blocs persos (info/attention/etc.), mais pas ceux contenu dans une balise de code ou minicode, ni puce, ni... C'est vite le gros bordel, sans parler des imbrications de balises, et notamment du cas des citations.

Je pense que si on veut attirer le maximum d'auteurs, il vaut mieux leur faciliter l'import des tutos plutôt que leur dire "démerdez vous".

Étant données les contraintes du zCode, si on veut faciliter l'import, alors il faudrait proposer deux modes : un avec les sauts de ligne pris en compte, et un sans.

[SpaceFox]

Si tu veux un coup de main pour qu'on essaie de trouver une solution, je peux t'aider.

[Coy0te]

Update : j'ai reparsé les cours, en échappant les dollars, corrigeant les tableaux qui présentaient un zCode merdique, et en tâchant d'appliquer des doubles sauts de ligne du mieux que possible.

Je vérifierai le résultat obtenu sur un batch de tutos sélectionnés au hasard ce soir, et je réuploaderai le tout dans la foulée sur le serveur.

[Edit] Arf, l'échappement des dollars a merdé. Je me pencherai dessus plus tard.

[Coy0te]

Coming soon, upload du rep /Sources_md à jour avec :

• tableaux foireux corrigés ;
• urls des images corrigées ;
• dollars échappés.

[firm1]

Fixé. Merci a @Coy0te