Markdown bug #57
Comments
ghost
assigned 
|
Histoire de faire mon chieur, je suis pas convaincu de ces meta-issue (plutôt qu'un tag / issue + milestone éventuelle) Sinon, à propos de bug, j'ai cru en voir quelques un dans le post fait sur ZdS :
|
C'est à dire ? |
|
Regarde les exemples des textes italiques et gras. Dans la balise code d'utilisation avec les edit : nevermind, il semblerait que ce soit une sorte d'erreur css ? |
|
Oui c'est à cause de la hauteur du bloc, un peu trop petite. Si tu descends un peu avec la scrollbar, tu les voies. En tout cas sur Chrome c'est comme ça. J'imagine que ce sera corrigé avec le nouveau design. |
|
En tout cas ce n'est pas un bug du markdown. On ne pourrat pas vérifier ça avant l'integration finale |
|
Sujet complété avec les limites/bugs de la syntaxe des tableaux. |
|
En ce qui concerne les tables multi-lignes, il faudrait, @cgabard si possible que tu intègres cette extension. ça rajouteras la syntaxe suivante : Qui est aussi celle de pandoc |
|
Pour le |, si l'échappement ne fonctionne pas, je pense voir comment faire pour que ce soit le cas, si tu pense que ça peut être une solution viable. Car dans tous les cas il faut pouvoir différentier les deux @medegit : La syntaxe actuel ne le permet pas. Je remarque que pandoc propose 2 autres syntaxes qui le permettes : http://johnmacfarlane.net/pandoc/demo/example9/pandocs-markdown.html :
Qu'en pense tu ? je vais voir ce qui se fait dans les extensions existantes |
|
Bon j'ai pas trouvé mieux que celle proposé par @firm1 Cela me plait comme solution car a priori je n'ai rien a codé et que c'est compatible pandoc. La grande question est de savoir si on autorise les deux syntaxe ou juste celle grid_tables |
|
Pour moi ça semble ok. Je sais encore pas trop comment le parseur devra se comporter sur les quelques tableaux qui utilisent du colspan et du rowspan, mais bon... Je vais me débrouiller. Du coup, tu me confirmes : je peux partir sur la syntaxe grid_tables pour la conversion zCode -> md ? |
|
En fait si tu regarde https://github.com/smartboyathome/Markdown-GridTables/blob/master/test_grid_tables.py tu verra que l'extension proposé par @firm1 supporte les colspan et rowspan. Celle de pandoc non, mais ça ce n'est pas le prob actuel. Yep je pense qu'on peut partir dessus. Reste a voir si je peux garder les deux d'activés sans que ça pose de probs. |
|
Ok, c'est cool ça ! Sûrement chiant à gérer pour moi à la traduction du zCode (xD), mais bonne nouvelle quand même. Je pars là-dessus. |
Je préfère qu'on autorise les deux syntaxe, parce qu'il y'en a une qui est plus simple a écrire à la main que l'autre. @medegit privilégie lors de l'import la deuxième syntaxe (gridtable) pour être sur que tout sera toujours dans le pack. |
|
@medegit : a priori je vais essayé de pousser ça rapidement. J'ai pas grand chose à faire vu que c'est déjà codé ! En attendant oui tu va pouvoir partir là dessus. @firm1 : Oui je vais tenter de garder les deux, normalement ça devrait le faire mais les syntaxes étant proches, on est jamais à l'abris d'une connerie. Je pense que ça va se jouer selon une question d'ordre de parsage. |
|
@ShigeruM : tu peux regarder la syntaxe de grid_tables expliqué plus haut pour les tableaux, en plus de celle précédente, pour mettre a jour ton tuto sur la syntaxe ? a priori les deux syntaxes seront supporté, celle de grid_table etant plus lourde mais permetant une édition plus avancé (colspan, rowspan, et multilignes dans les cellules, entre autre) |
|
Bon, j'ai commencé par bricoler un truc qui semble marcher pour les tableaux sans rowspan/colspan. Prévenez-moi dès que la syntaxe grid_tables est poussée sur ZdS, pour que je teste vite fait quelques trucs avant de continuer. |
|
Btw, qu'est-ce que je fais des "légendes" des tableaux ? Je les sors et les affiche en tant que texte centré et gras en dessous du tableau ? |
|
Dans une balise (HTML5). Le 6 janvier 2014 16:40, Coyote notifications@github.com a écrit :
|
C'est une solution qui me sied |
|
Argh. C'est dommage mais tant pis. 2014/1/6 firm1 notifications@github.com
|
|
Par contre, s'il est pas trop paresseux, il peut implementer le caption lui même. la syntaxe de pandoc pour celà, revient à faire un truc dans le genre : |
|
@medegit : Je pense envoyer ça à @firm1 demain soir, donc j'imagine que mercredi ce sera en prod Pour les captions, si ce n'est pas dans l'extension, je peux le mettre sur ma todo liste, dans une deuxième pass. Mais la même question se pose pour les images : est ce qu'on essait de les détecter comme figure et utiliser les balises html5 correspondantes ? si oui quelle syntaxe ? |
|
Pour les images, tu peux le mettre dans ta todolist avec la syntaxe de pandoc qui donne ceci :
Donc, du coup @medegit tu peux prendre ça en compte autant pour les tables que pour les images avec légendes ? |
|
Ce que tu met comme légende est normalement le texte alt. En gros, si je comprend bien, quand on trouve une image seule dans son pragraphe, on fait un rendue de figure plutot que de img, c'est ça ? |
|
je dirais les deux, alt et figure. |
|
Certes mais l'idée est là : transformer une balise img en figure (avec caption) si elle est seule dans son praragraphe ?! Cela ne me parrait pas specialement compliqué, au détail pret que je dois trouver un moyen de différencier un smiley d'une image classique. Car il va m'etre plus simple de faire une extension qui passe après la création des balises images (qui est intégré à python-markdown et donc pas facilement modifiable). |
Et donc tu confirmes donc à @medegit ce que tu feras, pour qu'il agisse dans le bon sens ? |
|
J'ai fait quelques tests, le parseur tourne bien, il ne reste plus que les tableaux à gérer correctement. Le souci avec les tableaux, c'est que j'ai réalisé ce matin que dans la syntaxe des tableaux grid_tables, il faut que les séparateurs de colonnes soient alignés verticalement pour que ça fonctionne, on ne peut pas dessiner les bordures à l'arrache (non alignées verticalement) comme on peut le faire avec une syntaxe comme pipe_tables. Donc a priori, faut dessiner un tableau dont les bordures des colonnes sont aussi larges que le contenu de leur plus longue cellule... Ça, plus les cas de rowspan/colspan, ça sent le truc ultra-méga-chiant à gérer, sans parler de la gueule du tableau dans la source du tuto, ni même du helper JS qu'il va falloir coder sur la zForm pour éviter à l'utilisateur de devoir aligner les bordures de ses tableaux avec une police à chasse non fixe...!). Autrement dit, les tableaux markdown façon ASCII art, ça va très bien pour les tableaux qui contiennent trois caractères par cellule, mais au-delà ça devient un peu n'importe quoi. Je continue mes tests et je verrai ce que mes rendus vont donner quand la syntaxe sera implémentée sur ZdS, mais je suis un peu sceptique. |
|
Si tu héberges ton code de parseur sur un repo git quelque part et qu'il est fait en java, ça m’intéresserai de le voir, je pourrais te faire des suggestion dessus vue que je suis globalement plus efficace en Java qu'en python. |
|
@medegit Et en checkant rapidement Google, je suis tombé sur ceci, qui va surrement te faciliter encore plus la tache. |
|
En soit c'est surtout pour toi le prob. Pour les auteurs ils auront les deux syntaxes à dispo donc la syntaxe grid_table sera réservé à ceux qui veulent faire des trucs avancés. A eux de faire attention à leur code. Mais dans tous les cas, il ne semble pas y avoir de syntaxe miracle a la fois simple et permetant le colspan, rowspan et le multiligne. Apres si quelqu'un pond une solution parfaite, je peux l'implémenter (mais ça prendra plus de temps. |
|
Il reste toujours la possibilité d'autorisé les tableaux avec du code html mais
|
|
Merci @firm1 pour l'API ascii, ça va simplifier le travail. |
|
Bah, les auteurs, ils auront à moyen terme un éditeur de tableau fait en JS (faut que je crée l'issue). Donc, on est a peu près sur que celui qui se rate, c'est son problème. |
|
Bon moi les je ferais la mise a jour du markdown demain soir finalement. J'ai du temps de dispo demain aprem, normalement je devrait pouvoir pousser les tableaux (avec si possible les legendes), les smiley, les commentaires voire le truc des figures. J'ai oublié un truc ? |
|
Pour le moment je pars sur l'ascii style, on verra ce que ça donne. |
|
Oui mais pandoc n'est pas utilisé. On envisage de le prendre pour générer les pdf & ebook, et c'est pour ça que l'on cherche a rester proche de sa syntaxe au possible, mais c'est python-markdown qui est utilisé sur le site. Et lui il me semble qu'il n'est pas specialement fait pour ça (à vérifier, je suis passé vite dans ce code là) |
|
Bon j'ai une branche avec smiley, tableaux en grille et légende de tableaux. Cependant les légendes necessites actuellement une ligne vide entre les deux. C'est dut a l'extension de grille... Je vais voir pour gérer tout de même le cas ou les deux sont collées. |
|
Si jamais le saut de ligne est obligatoire, préviens-moi pour que je le rajoute à la conversion zCode. |
|
C'est bon, la légende doit être en dessous sans lignes entre les deux, compatible pandoc ! |
|
Ok et donc lorsque une image est isolé dans son paragraphe, à la racine de la page, dans un quote ou dans une de nos custom box (secret & co), elle est transformée en figure avec caption.
Je fais la PR, firm1 va pouvoir te le pousser rapidement et te permettre de me trouver de nouveaux bugs ou trucs à faire |
|
Je suis un peu mitigé au sujet de la transformation des images présentes dans les custom box :
En gros, c'est peut-être moins grave de faire en sorte qu'une image ne soit plus une figure lorsqu'elle est citée, que l'inverse. Non ? |
|
Que ce soit dans les box ou les citations, il faut toujours que l'image soit isolé et pas inline pour qu'elle se transforme en figure. En gros c'est pour que si tu cite un message contenant une figure il reste figure, c'est tout. Quand je parle de ça, ce sont les endroits où je vais chercher les balises image isolées : a la racine, dans les citations et les box. Mais pas dans un tableau par exemple, une image dans une case restera une image et pas une figure quelle soit isolée ou non. |
|
Ok, j'avais compris de travers. |
|
On en avait déjà parlé il y a un moment, mais dans les tutos convertis il y a pas mal de sections En plus de la non interprétation des passages contenant des sauts de lignes (ça au pire, c'est pas hyper grave), certains éléments de syntaxe se retrouvent non interprétés également. Ce n'est pas le cas du gras ou des listes par exemple, qui sont très bien gérés, mais c'est le cas des tableaux. C'est possible de corriger ça ? |
|
Hum effectivement... Les sauts de lignes necessitent d'être revus. Normalement le tableau devrait passer, je ne sais pas pourquoi ça ne passe pas. J'ai changé pas mal de choses et apprit pas mal sur le fonctionnement de python-markdown depuis. Je devrait pouvoir faire mieux. Mais j'ai peur de ne pas pouvoir correctement traiter, par exemple, un décalage à l'interieur d'un autre... |
|
Si jamais ça peut aider, le tableau doit être parfaitement aligné pour fonctionner, donc être converti avant le remplacement des blocs d'alignement (pour s'assurer que rien ne sera introduit au début de la première ligne du tableau notamment).
Si tu parles d’alignements imbriqués, c'est pas censé arriver, pas besoin de se prendre la tête ici. |
|
Oui, l'extension grid_table est ultra sensible et je pense que c'est probablement ça qui la gène. Car normalement, dans le contenu du code aligné, tout doit etre re-parsé donc le tableau devrait être trouvé. |
|
Dans ce cas, ce qu'il manque c'est peut-être juste un saut de ligne avant/après le tableau, j'ai déjà remarqué qu'un tableau n'étais pas interprété s'il n'était pas entouré par des sauts de ligne en haut et en bas. |
|
Oui. Ce serait cependant bien que j'assouplisse un peu les regles, car cette extension est ultra pénible. Je l'ai déjà empeché de provoquer un 404 à chaque tableau mal formé. Mais j'ai un peu la flemme de la recoder entièrement là... |
|
Je viens de vérifier, il suffit de mettre un saut de ligne avant et après un tableau pour qu'il soit interprété. Je vais forcer ce comportement dans le parseur zCode. Ça ne changera rien au fait que les sauts de lignes ne sont pas gérés dans un bloc aligné, mais au moins un tableau placé dans un bloc aligné sera correctement interprété, c'est déjà ça. |
|
Je viens de vérifier, les citations passent bien. Or ce sont le même type d'extension que les tableaux. Ça doit effectivement être une connerie du genre, je regarderais ce soir si j'ai le temps |
|
Petit bug remarqué ce matin : quand un auteur écrit le caractère $ en dehors d'une balise code, le caractère est interprété comme un début de balise maths. Faut-il systématiquement l'échapper avec un \ ? Si oui, ça veut dire que je vais devoir échapper tous les $ contenus dans les tutos SdZ, sauf ceux qui sont contenus dans des balises code ou minicode... Autre truc qui ressemble à un bug :
|
|
Je ferme cette issue, c'etait une mauvaise idée de tout regrouper, j'en fait des indépendantes à la place. |
|
Normalement j'ai fais des issues indépendantes pour tout ce qui doit etre fait. Si vous en voyez d'autres, créez en une et assignez moi ! |
J'ouvre cette issue pour répertorier les bugs connus dans le markdown du site.
Une autre issue est ouverte pour discuter et répertorier les features demandées : changement de syntaxe, nouveau comportement, nouvelle extension, etc... : #58
Ici on se concentre sur les bugs.
Actuellement de connus :
La syntaxe de code "à la git hub" ne fonctionne pas dans des blocs persos ou citation : Ce bug a normalement été résolu mais n'est pas encore poussé en prod.Les smiley s'insères n'importe comment dans les codes ou messagesLa syntaxe actuelle des tableaux ne permet pas les sauts de ligne au sein d'une cellule, ni l'utilisation du caractère |.N’hésitez pas si vous en voyez d'autres.
The text was updated successfully, but these errors were encountered: