zmarkdown

Bon en fait j’ai effectivement trouvé beaucoup plus propre et simple qu’ajouter \displaystyle.

Ça a l’air d’être au top !

Je t’en prie, content d’avoir trouvé une solution convenable.

Maintenant j’espère juste que j’arrive à convaincre l’auteur de la lib d’y intégrer ça, sinon ça va être chiant à maintenir.

Première bonne nouvelle : ma PR sur le module de parsing latex a été acceptée après pas mal de discussions et de réflexion, du coup pas besoin de monkey-patcher le bouzin. C’est top !

On a fait quelques progrès sur le markdown, désormais y’a des smileys ! Grace à un contributeur de plus !

Si vous voulez aider, on a plein d’exemples, un outil simple pour vous guider, plein de tests, et un coverage splendide. Jetez un oeil ici pour savoir quels tests restent à faire passer : https://travis-ci.org/zestedesavoir/zmarkdown/builds/216946228 et jetez un oeil aux issues ouvertes ! Merci d’avance.

(J’oubliais de préciser : c’est pas chiant à installer et à contribuer ! Vraiment pas ! Sur mon petit laptop, cloner le repo à neuf puis faire yarn && npm run test pour installer les dépendances et lancer la suite de test prend moins de 7 secondes. 6s pour installer les dépendances, 583ms pour faire passer les 92 tests actuels.)

Question de béotien : si c’est fait en JS, en prod, ça risque de pas poser problème ? À moins que c’est parsé côté serveur et non client ?

Non, je pense pas que ça pose problème. Ce sera fait côté serveur, mais ça permettrait aussi d’envisager une prévisualisation côté client sans faire d’AJAX.

Sinon, j’ai forké le dépôt et je vais voir si je peux faire quelques trucs pour aider (même si je m’y connais peu en JS).

Comme l’a dit GCodeur, on va continuer à parser côté serveur. Par contre ouais, la prévisualisation sera nettement mieux vu qu’elle utilisera le même parseur, et le tout dans le navigateur ! Cf. https://zestedesavoir.github.io/zmarkdown/public/

On a désormais plus de tests qui passent (95) que de tests skippés (93). Par contre il reste des choses à éclaircir dans quelles fonctionnalités de python-zmarkdown il nous faut impérativement répliquer.

Voici ce qui passe pas encore, annoté avec quelques questions :

• #basic
  • literal-quotes.txt
  • markdown-syntax.txt
• #extensions
  • #extra
    • abbr.txt
    • extra_config.txt ça fait quoi ? C’est utilisé ?
    • footnote_placeholder.txt ça fait quoi ? C’est utilisé ?
    • markdown-syntax.txt
    • named_markers.txt C’est utilisé ?
    • tables.txt
• #misc
  • autolinks_with_asterisks.txt
  • backtick-escape.txt
  • blockquote-hr.txt
  • brackets-in-img-title.txt
  • comments.txt
  • em_strong_complex.txt
  • funky-list.txt
  • h1.txt
  • hash.txt
  • header-in-lists.txt
  • headers.txt
  • hline.txt
  • html-comments.txt
  • html.txt
  • lists6.txt
  • markup-inside-p.txt
  • missing-link-def.txt
  • more_comments.txt
  • multi-test.txt
  • multiline-comments.txt
  • nested-lists.txt
  • pre.txt
  • raw_whitespace.txt
  • some-test.txt
  • stronintags.txt
  • tabs-in-lists.txt
  • two-spaces.txt
  • uche.txt
  • url_spaces.txt
• #options
• #php
  • Email auto links.txt
  • Inline HTML (Simple).txt
  • Links, inline style.txt
  • Nesting.txt
  • Parens in URL.txt
  • Tight blocks.txt
• #pl
  • #Tests_2004
    • Amps and angle encoding.txt
    • Auto links.txt
    • Backslash escapes.txt
    • Blockquotes with code blocks.txt
    • Hard-wrapped paragraphs with list-like lines.txt
    • Horizontal rules.txt
    • Inline HTML (Advanced).txt
    • Inline HTML (Simple).txt
    • Inline HTML comments.txt
    • Links, inline style.txt
    • Links, reference style.txt
    • Literal quotes in titles.txt
    • Markdown Documentation - Basics.txt
    • Markdown Documentation - Syntax.txt
    • Nested blockquotes.txt
    • Ordered and unordered lists.txt
    • Strong and em together.txt
    • Tabs.txt
    • Tidyness.txt
    • Yuri-Attributes.txt
    • Yuri-Email.txt
    • Yuri-Links-in-Headers.txt
  • #Tests_2007
    • Hard-wrapped paragraphs with list-like lines.txt
    • Inline HTML (Advanced).txt
    • Inline HTML (Simple).txt
    • Inline HTML comments.txt
    • Links, inline style.txt
    • Links, shortcut references.txt
    • Literal quotes in titles.txt
    • Ordered and unordered lists.txt
    • Tabs.txt

Aussi :

• J’ai vraiment besoin d’aide sur ces points.
• J’apprécie toutes infos au sujet de n’importe quel test ci-dessus ! Pas seulement ceux que j’ai mis en gras !
• Est-ce que quelqu’un qui connait le module de typo francophone de ZdS peut jeter un oeil à zmarkdown et se mettre à disposition pour en discuter ?
• Est-ce qu’il est nécessaire de pouvoir mettre un titre dans une liste ? C’est une fonctionnalité propre à ZdS dont je ne vois pas l’utilité.

Merci

=> hline il me semble que c’est un truc qui génère un <hr> non?

Concernant la balise spoiler, serait-il plus judicieux d’utiliser les balises HTML detail et summary (en sachant que ce n’est pas supporté par les boulets IE, Edge et Opera Mini) ?

Sources :
- https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details
- https://www.alsacreations.com/article/lire/1335-html5-details-summary.html
- http://caniuse.com/#search=detail

Non, regarde : https://github.com/zestedesavoir/zmarkdown/blob/master/test/fixtures/misc/hline.txt

A voir, pas sûr. Si on passe par details/summary, je serais pour en autoriser la syntaxe directement dans le markdown et peu à peu décourager l’usage de la balise spoiler actuelle. On verra.

Pour em_strong_complex :

• c’est un cas particulier du md zds qui accepte des trucs chelou et mixed style___test test__ test test_ qui doit générer <em><strong>test test</strong> test test</em>.
• je suis à peu près certains que certains tests ont été créés pour masquer des bugs de pyzmarkdown exemple pour **test*** que pyzmarkdown interprète comme <strong>test</strong>* alors que perso (et zmarkdown est ok avec moi) produit <strong>test*</strong>

La gestion des em/strong complexe est merdique dans la version actuelle.

Pour toute la partie : zds "rediger_sur_zds_partX.txt" voici ce qu’on a globalement

• on a l’apostrophe français chez pyzmd alors que l’apostrophe droit est dans zmarkdown
• dans les codes, on a remplacé la classe codehilite par language-text
• on gère assez mal les captions
• on n’a pas mis les identifiants sur les titres
• la part5 fait planter le zmarkdown
• les tableaux à la ReST ne sont pas parsés
• on a globalement changé la structure des blocs de codes.

Pour la partie sur php, il s’agit, il me semble d’overrider la balise de code php pour que l’entête <?php ne soit pas obligatoire.

Simple question, qu’est est l’avantage à parser coté serveur ?

Et sinon, on pourrait pas en profiter pour avoir une prévisualisation temps réel ?

Simple question, qu’est est l’avantage à parser coté serveur ?

• les check
• la prégénération
• le cache

La démo, là, c’est en temps réel. Tu peux éditer le Markdown dans le champ en haut à gauche.

Pense aux risques qu’on prend si le client envoie l’HTML au serveur.

Parser que coté client c’est trop dangereux. Cependant un parseur en JS a l’avantage de permettre de parser des deux cotés de façon identique. On gagne sur tous les tableaux.

On (Amar0k, artragis et moi) a fait de bons progrès ce week-end, voici à nouveau le lien de la démo : https://zestedesavoir.github.io/zmarkdown/public/

Cadre en bas à gauche, l’AST à partir duquel on sortira le LaTeX, grâce au super template que nous préparent Karnaj et pierre-24 !

Comme vous pouvez voir dans l’AST, nos noeuds "custom" sont bien visibles et seront faciles à compiler. Typiquement attentionCustomBlock, ou kbd.

Les maths devraient être bonnes aussi, il y a donc 3 environnements :

• foo $bar$ baz -> inline
• foo $$bar$$ baz -> display dans le paragraphe
• $$bar$$ -> display hors paragraphe

J’ai aussi extrait chaque plugin dans son propre packet et les ai tous publiés sur npm grâce à Lerna. Les tests sont nettement plus simples à écrire désormais, et donc tout est plus simple à comprendre. La plupart des packets ont un coverage de 100%.

J’ai aussi commencé à rédiger des READMEs potables, comme ici. Aide bienvenue.

J’ai aussi pris la liberté de tout publier sous MIT (c) ZDS, cf. LICENSE-MIT sur le repo.

Je plussoie le MIT.

Vive les jours fériés. J’ai pu débuter la compilation de l’AST Markdown vers LaTeX.

Avec le cool template de Karnaj et pierre_24, j’en suis là :

Le compilo vers LaTeX se trouve ici pour les curieux : https://github.com/zestedesavoir/zmarkdown/tree/master/packages/rebber