• [^] # Re: support (des) Markdown

    Posté par (site web personnel) . En réponse à la dépêche LibreOffice 26.2 : Markdown, accessibilité et plein d’autres nouveautés et améliorations. Évalué à 2.

    Tu peux m'expliquer comment LibreOffice peut prendre en compte toutes les moutures de Markdown quand il y en a quasiment une par site qui accepte le Markdown ? C'est tâche plutôt impossible.

    Réponse courte : non à ta tautologie_ et non (toi tu choisis « à l'impossible nul n'est tenu » moi, je le prends au sens « ils ne savaient pas que c'était impossible, ils l'ont fait » ah bah oui, le premier est ambivalent :-)

    Réponse moins courte (mais pas complète) :

    toutes non, c'est illusoire et contribue à ta tautologie auto-réalisatrice (hormis ton plutôt, l'ami de Mickey< j'imagine ?) ; plusieurs oui : soit liste statique choisie par l'utilisateur, voire définie par l'utilisateur (ce pourquoi un éditeur Markdown doit1 conserver la syntaxe retenue par l'utilisateur)

    Ce pourquoi je parle de mouture — un peu comme les déclinaisons en latin, leur nombre reste pour autant fini (hormis les exceptions) — sans l'information de « quel » Markdown appliquer ça ne peut que ne pas convenir :/

    Le Markdown c'est à la fois la représentation textuelle et le rendu HTML (ou PDF, ou ePub, ou ODT...) déjà ce serait pas mal de respecter cela, sachant que Markdown n'est pas univoque (plusieurs manières d'obtenir le même résultat en rendu HTML mais représentation différente en texte, ce n'est pas bijectif non plus)

    Par exemple et de manière non exhaustive :

    • si l'utilisateur a choisi les titres avec des # c'est ce qu'il faut conserver, idem si choix des soulignés en dessous ---------, idem si choix des === autour (ce que LinuxFr.org ne propose pas)
    • si l'utilisateur a choisi les listes avec - pour premier niveau et - pour deuxième niveau, c'est ce qu'il faut conserver, pas le transformer en * et **
    • si 2^8 est censé afficher 28 : soit le gérer — mais il faut pouvoir étendre la mouture de Markdown retenu), soit le conserver tel quel pour ne pas pourrir le texte initial — proposer de remplacer par 2^8^ n'est pas valide pour le Markdown retenu par l'utilisateur
    • il y a quelques spécificités du Markdown : on peut vouloir d'un correcteur orthogrammatical mais sans ses modifications silencieuses ; par exemple, ajouter silencieusement une espace insécable devant : est inacceptable car cela peut faire partie de la syntaxe de Markdown ; bref, le signifiant n'est pas forcément exprimé. Il y a le même souci avec des § qui mixeraient anglais et français et ce n'est effectivement pas un problème simple ;-)

    bref, je ne vais pas faire la spec complète de besoins utilisateurs, encore moins la description exhaustive des syntaxes de Markdown, encore moins l'implémentation, simplement retenir 2 points qui me semblent important pour qu'un éditeur Markdown générique fonctionne :

    • choix de la mouture Markdown retenue par l'utilisateur et respect de la syntaxe choisie
    • possibilité d'extension et — à défaut — conserver la syntaxe initiale sans l'enlever

    Et LinuxFr a son propre Markdown qui n'est pas le même que celui du voisin de palier, etc.

    d'où mes 2 points précédents

    C'est quoi le problème avec "support" ?

    ceci est laissé à titre d'exercice ; indication : c'est parfois une bonne habitude de lire les liens fournis qui ont le mérite d'indiquer ce qui m'insupporte :p


    1. doit au sens de la RFC 2119 qui définit aussi devrait, pourrait, recommanderait...