Journal Saletés de codes différents et tutoriel wiki

4
19
avr.
2019

Dans la série de trucs qui rendent fou et qui donnent envie de pendre les développeurs et les développeuses par les tripes ou, a minima, de les forcer à manger des pizzas à peine décongelées sans ketchup ni coca pour faire passer (oui je sais, gros poncif), les différences de signification des caractères selon les codes est tout en haut de la file. Mais vraiment en haut, plus haut y’a plus rien.

Exemple

Après avoir pondu un tutoriel pour le wiki de Linuxfr sur l’art et la manière d’écrire confortablement une dépêche, un journal ou même une page de wiki avec Writer de LibreOffice et concocté un modèle pour faciliter encore plus le travail, je commence à traduire une page du wiki de Mageia en espagnol (on travaille durement autour du chaudron de Mageia pour la sortie de la prochaine version).
Pour ce genre de travail, je préfère commencer par utiliser mon traitement de texte favori, c’est plus confortable, ensuite je balance le tout sur le wiki. Et, évidemment, je commence par générer mon document à partir de mon modèle tout neuf de saisie d’article pour syntaxe Markdown. Jusque-là, tout va bien.
La page en question porte justement sur « comment écrire une page wiki » et là, de quoi m’aperçois-je ? Qu’il y a quelques différences de syntaxe. Rahhhh ! Déjà que pour ajouter ce tutoriel, rédigé pour Linuxfr et avec la syntaxe Markdown, à un de mes sites sous SPIP j’ai dû revoir pas mal de trucs parce que la syntaxe n’est pas tout à fait la même.

Pourquoi, mais pourquoi ?

Il y a une raison fondamentale pour que les crochets, les parenthèses, les astérisques, les accolades, etc. n’aient pas le même rôle dans les divers langages de programmation ?
Il y a une raison fondamentale pour qu’en fonction du langage on doive écrire un bête lien hypertexte de façon différente ?
À part rendre chèvre les gens, évidemment ?
Développeurs et développeuses de tous les pays, s’il-vous-plaît, unissez-vous pour unifier tout le bazar (quelque chose me dit qu’on va m’expliquer que c’est pas possible).

Modèle

Sinon et plus sérieusement, le modèle de document LibreOffice dont je parle est aussi téléchargeable sur la page wiki qui vous explique comment rédiger avec LibreOffice pour Linuxfr. Très sérieusement, ça facilite la vie.

  • # Il faudrait une nouvelle norme!

    Posté par  (site web personnel) . Évalué à 10.

    xkcd sur les standards

    • [^] # Re: Il faudrait une nouvelle norme!

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Je savais bien qu'on me suggèrerait que c'est pas possible.

      Reste plus qu'à imaginer d'autres supplices pour la gens développeuse.

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: Il faudrait une nouvelle norme!

        Posté par  (site web personnel) . Évalué à 9.

        Reste plus qu'à imaginer d'autres supplices pour la gens développeuse.

        Ça a déjà été fait. Par exemple le langage TeX n'a pas de syntaxe à proprement parler : un document TeX peut dynamiquement redéfinir toute la syntaxe du compilateur et de fait c'est une « fonctionnalité » très utilisée. Ça permet d'écrire les séquences foo!42!bar!!+++ (xcolor) ou ?[l]f*_ij^{}kl? (tensid), parfaitement valides et sensées pour TeX.

        Certains y voient outrages à l'interopérabilité, d'autres y voient une source de défi, et les habitués de cette pratique voient probablement Markdown comme un carcan syntaxique qui n'offre aucune liberté.

        Adhérer à l'April, ça vous tente ?

    • [^] # Re: Il faudrait une nouvelle norme!

      Posté par  . Évalué à 3.

      Et aller, encore un XKCD posté sans alt-text et sans lien… https://xkcd.com/927/

  • # Markdown pas uniforme

    Posté par  . Évalué à 2. Dernière modification le 19 avril 2019 à 15:06.

    Ptite confirmation que sur Dokuwiki le markdown n'est pas non plus compatible avec le markdown de LinuxFR.

    J'ai toujours préféré le BBCODE, plus stable et toujours avec des balises fermantes qui évite des bugs du type :

    1. Je
    suis
    
    1. buggé
    • [^] # Abus de langage !

      Posté par  . Évalué à 2.

      Markdown est un langage de balisage, un parmi d'autres. Dokuwiki a le sien, org-mode a le sien.

      Markdown écrase un peu tout à l'heure actuelle, grâce à son utilisation par les sources logicielles type github.

      «Mal nommer les choses, c'est ajouter au malheur du monde.»
      Albert Camus

  • # Plutôt que de râler ...

    Posté par  . Évalué à 1.

    Choisis en un et code la moulinette pour lui faire cracher l'équivalent selon les autres syntaxes.
    Avec un tel outil, il y a peut être moyen d'imposer celui que tu auras choisi comme LE standard ;-)

  • # Les langages c'est un peu comme les langues

    Posté par  (site web personnel) . Évalué à 7.

    De la même façon qu'il n'y a pas de langue universelle, c'est difficile d'avoir des langages de programmation universels. Parfois certaines langues réussissent à se faire une plus grande part de marché que d'autres, comme l'anglais (même si au fond c'est à peine 10% de la planète qui le parle plus ou moins couramment). De même, certains langages, comme Markdown, s'en sortent mieux que d'autres; en fait, par rapport à l'anglais, Markdown est probablement plus hégémonique. Cependant, tout comme avec l'anglais, il y a différents types de Markdown, avec plus ou moins d'extensions/variantes. Encore ici, il y a au fond beaucoup moins de variabilité dans le Markdown (voire en incluant d'autres syntaxes type wiki) que dans l'anglais.

    Ceci dit, la différence avec les langues, c'est que bien que celles-ci servent à peu près à la même chose et ont les mêmes fonctionnalités de base, les langages de programmation par contre diffèrent souvent dans leurs utilisations et caractéristiques de base. D'un autre côté, les langages de programmation sont plus simples aussi. Mais bon, dans l'idée, je pense que le manque d'homogénéité dans ce domaine s'explique par des raisons assez similaires au manque d'homogénéité dans les langues : qu'individuellement, les gens ont rarement besoin de communiquer avec l'ensemble de la planète et, comme il y a beaucoup d'individus, il y a beaucoup de petits groupes qui naissent indépendamment.

    • [^] # Re: Les langages c'est un peu comme les langues

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Oui je sais. Mais bon, quand on travaille sur un texte avec une syntaxe particulière et qu'on doit ensuite changer des trucs parce que la syntaxe change, ça gave, surtout quand tu croyais naïvement avoir affaire à la même syntaxe parce que c'est le même type de site. Et ben non.

      Bon, pas grave mais ça donne tout de même envie de tordre le cou des devs sur le coup.

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

    • [^] # Re: Les langages c'est un peu comme les langues

      Posté par  . Évalué à 3.

      Il y a une différence entre langages de programmation universels et variantes de markdown qui se ressemblent à 70%, et que les 30% restant vont vous faire passer votre temps à lire la doc plutôt que de taper le texte vite fait bien fait. Non, là on parle plutôt de genre mélanger python 1, python 2 et python 3 sans avoir la commande pour connaître la version de celui que vous utilisez. C'est la différence entre Word 97 et Word 2000 et Word XP et Word d'Office 365. C'est le bouton 3 de votre ascenseur qui vous amène au 6ème étage parce que l'étiquette est fausse.

      Bref, c'est une absence de standard qui fait perdre du temps.

  • # Wiki, Markdown

    Posté par  . Évalué à 2. Dernière modification le 19 avril 2019 à 19:09.

    Face à la multitude de syntaxes Wiki, Markdown et compagnie, j'ai laissé tomber depuis longtemps tout ça et utilise du WYSIWYG. La syntaxe Wiki censée faire gagner du temps en fait perdre en réalité, on est tout le temps en train de se demander ce qu'il faut écrire ou non. Même Wikipedia a intégré du WYSIWYG et heureusement sinon, il n'y aurait plus de nouveaux contributeurs.

    • [^] # Re: Wiki, Markdown

      Posté par  . Évalué à 6. Dernière modification le 19 avril 2019 à 19:58.

      De mon côté je n'ai toujours pas compris en quoi taper du HTML pur comme <h1>truc</h1> ou <b>bidule</b> ou <ul><li>...</li></ul> était tellement plus compliqué que les 50 variantes de syntaxe wiki incompatibles… (et avec des libs comme Mathjax ou jqmath on peut même taper des équations de manière sympa en HTML…)

      • [^] # Re: Wiki, Markdown

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Et pas forcément moins lisible (ou plus).

        Personnellement la syntaxe wiki pour faire des tableaux me bousille les yeux.

        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: Wiki, Markdown

        Posté par  (site web personnel) . Évalué à 3.

        … mais quel est l'intérêt de taper soi-même les balises (par rapport à un éditeur WYSIWYG) ?

        • [^] # Re: Wiki, Markdown

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Et bien parce que travailler avec un traitement de texte t'apporte un confort que ne t'apporte pas par exemple la saisie de texte d'une dépêche pour Linuxfr. D'ailleurs si tu avais lu ce journal tu aurais compris de toi-même.

          Utiliser le traitement de texte c'est aussi utiliser un outil de correction orthographique, grammaticale et orthotypographique puissant et, quand on aime bien avoir des textes propres, c'est plus simple que toutes les simagrées auxquelles il faut se livrer quand tu utilises les éditeurs wiki. Pas compliqué. Par ailleurs, un outil comme Writer te permet d'insérer des caractères spéciaux avec une facilité déconcetante tout en restant face à ton texte et sans passer par les va-et-vient auxquels te contraint la saisie d'une dépêche sur Linuxfr.

          Sans parler des textes avec des citations multilingues.

          « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

        • [^] # Re: Wiki, Markdown

          Posté par  . Évalué à 4.

          quel est l'intérêt de taper soi-même les balises (par rapport à un éditeur WYSIWYG) ?

          Il y a un intérêt côté développeur : une appli ayant peu de moyens est plus facile a développer lorsque l'éditeur est un bête champ texte.

      • [^] # Re: Wiki, Markdown

        Posté par  . Évalué à 2.

        C'est conçu pour être raisonnablement lisible sans interpréteur, pas spécialement pour être plus simple à taper.

    • [^] # Re: Wiki, Markdown

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Rien que pour les liens hypertexte, des fois il faut mettre le texte du lien avant le lien, des fois après et, selon les langages, encadré de crochets, de parenthèses ou de signes inférieur et supérieur avec ou sans le texte du lien. Il y a de quoi perdre son latin.

      Mais bon. Je n'ai plus qu'à me faire un modèle pour le wiki de Mageia et à le proposer et puis c'est tout.

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: Wiki, Markdown

        Posté par  . Évalué à 3.

        Effectivement, les auteurs de ces langages n'ont en général pas lu la RFC de Berners-Lee et Fielding sur la définition des URI (RFC 3986) qui a explicitement autorisé les espaces comme délimiteur d'URL, ce qui est en général pratique et tout à fait adapté à des langages « humains » sans balisage. L'autre manière standard sont les signes inférieurs/supérieurs (utilisés historiquement dans les textes comme les e-mail depuis le début de son existence), qui ont été ré-inventés avec les crochets et/ou parenthèses et qui foutent le bazar car ce sont normalement des caractères autorisés dans une URL. Bref, de la réinvention de la roue.

        Pour moi, le seul qui respecte à peu près bien cet esprit est reStructuredText, dont il n'existe qu'une version car le modèle de gouvernance de Python fait qu'on essaye de faire des trucs cohérents et pas chacun dans son coin.

    • [^] # Re: Wiki, Markdown

      Posté par  (Mastodon) . Évalué à 1.

      La question du langage de balisage est totalement indépendante du choix de l'éditeur (WYSIWYG ou WYSIWYM) utilisé. Je ne vois vraiment pas le rapport.

      Markdown et d'autres langages de balises comme celui de dokuwiki ou asciidoc sont faits pour que le texte reste lisible à l'état brut tout tout en étant facile à parser et converti en html, pdf ou autre. Maintenant est-ce qu'on a besoin d'un langage universel ? Ce serait cool mais bonne chance pour trouver un consensus.

      En attendant comme dit plus haut il y a pandoc qui remplit bien son rôle.

  • # Intérêt réel du Markdown ?

    Posté par  (site web personnel) . Évalué à 1.

    Je trouve qu'il est très souvent plus pertinent d'utiliser un éditeur WYSIWIG utilisant un sous-ensemble bien réduit du HTML qu'un texte Markdown, par exemple CKeditor5.

    CKeditor (à partir de la version 5) a sa propre représentation en mémoire, mais stocke l'info sous la forme d'un HTML «normalisé» avec plein d'avantages :
    - il est facile à parser (beaucoup plus facilement que du Markdown, par expérience),
    - il est facile à sécuriser (il suffit de prendre un parseur HTML pour le recracher à l'identique en utilisant une liste blanche de tags et d'attributs),
    - il est facile à transformer vers d'autres langages (pour avoir fait une conversion Markdown vers LaTeX et la même chose depuis CKEditor, c'est bien plus facile avec le HTML normalisé),
    - c'est du WYSIWIG donc plus d'erreurs de rendu très étranges comme avec le Markdown,
    - on a le résultat en direct (je ne vois pas l'intérêt de ne pas l'avoir, en fait),
    - on n'a pas besoin de chercher pour faire quelque chose d'aussi simple qu'un lien hypertexte.

    • [^] # Re: Intérêt réel du Markdown ?

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Par rapport à HTML, les syntaxes comme Markdown / BBCode sont utiles pour empêcher l'injection de code malicieux dans ton site.

      Pour les sites, c'est donc bien plus simple de valider le texte reçu de l'utilisateur:

      1. il vire tout le code HTML qui pourrait y être présent
      2. il lit le reste avec la syntaxe qu'il a choisi
      3. il fait un rendu pour l'utilisateur et demande la confirmation à l'utilisateur.

      Il serait également possible de définir un sous-ensemble des tags et attributs HTML et faire le même travail en théorie. Mais ça demande plus d'investissement: il faut utiliser une représentation XML et l'utiliser pour enlever tout ce qui n'est pas dans ta liste blanche de balises et attributs HTML.

      • [^] # Re: Intérêt réel du Markdown ?

        Posté par  (site web personnel) . Évalué à 2.

        C'est exactement ce que je dis : c'est très facile de choisir un sous-ensemble de HTML à sécuriser, beaucoup plus facile en tout cas que de faire un parser fiable, assez complet, et toujours prévisible de Markdown.
        Le Markdown est extrêmement limité et en gros dès que tu sors du gros et de l'italique, c'est la catastrophe.

    • [^] # Re: Intérêt réel du Markdown ?

      Posté par  (site web personnel) . Évalué à 2.

      Je trouve qu'il est très souvent plus pertinent d'utiliser un éditeur WYSIWIG utilisant un sous-ensemble bien réduit du HTML qu'un texte Markdown, par exemple CKeditor5.

      C'est un contresens historique. Le format, ou plutôt les formats, Markdown sont en gros une formalisation du marquage informel qu'on utilise ou utilisait dans les courriels et les messages Usenet, formalisation à laquelle s'ajoutent des extensions (notamment pour les hyperliens les images et les tableaux). Mais le cœur de la syntaxe (le gras, l'italique, les listes, les citations et les “snippets”) sont compris depuis longtemps par certains clients mails, et n'a pas été définit a priori mais résulte d'une pratique existante.

      Le Markdown est né d'un usage légitime puisqu'il s'agissait d'ajouter un peu de formatage à un support purement textuel.

      Sinon il me semble que le Rich Text Format est sémantiquement équivalent à un sous-ensemble du HTML et si on tient à préparer son texte avec un éditeur WYSIWYG ce serait peut-être un choix plus intéressant qu'un sous-ensemble du HTML, à cause du nombre d'éditeurs disponible.

  • # CommonMark

    Posté par  . Évalué à 7.

    Markdown a été décrit succinctement il y a 13 ans sur le blog de John Gruber. À partir de 2012 Jeff Atwood avec d'autres a tenté de véritablement normaliser markdown, mais Gruber leur ayant refusé l'utilisation du nom markdown, ils ont appelé leurs travaux CommonMark. Bref ça n'a pas marché. John Gruber est contre cette normalisation pour lui, les gens ont des besoins différents donc ils font les choses différemment

  • # Complètement d'accord

    Posté par  . Évalué à 2. Dernière modification le 23 avril 2019 à 04:10.

    Oui la multiplication des syntaxes de langage de balisage, mais aussi des langages de programmation, et l'aspect le plus contre-productif et le plus inutilement couteux en énergie de l'informatique actuelle.

    • [^] # Re: Complètement d'accord

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Et quand, à un petit niveau, on doit en utiliser plusieurs comme : html voire xml, css, php plus wiki, markdown, on finit par être complètement perdu.

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.