Markdown est la syntaxe wiki retenue pour écrire sur LinuxFr.org.
John Gruber a publié les principes généraux du Markdown en 2004, avec une suite de tests et une implémentation de référence en Perl. Il est donc considéré comme le créateur du langage. Mais sa suite de tests est très incomplète et son implémentation de référence donne des résultats parfois surprenants sur des cas particuliers (les listes imbriquées notamment).
De nombreuses autres implémentations dans différents langages sont apparues depuis. Certaines essaient de corriger les « erreurs » de la version initiale pour mieux coller aux attentes des utilisateurs, tandis que d’autres préfèrent y rester conforme. Le premier camp réunit cependant toutes les implémentations les plus utilisées (GitHub, Stack Overflow, Discourse, LinuxFr.org — dont les particularités sont détaillées sur la page wiki pour l’aide-édition —, etc.). Aussi, les développeurs des principales bibliothèques se sont regroupés pour discuter des difficultés à implémenter un Markdown qui plaise à leurs utilisateurs et chercher à minimiser les différences entre les sorties des différentes implémentations : CommonMark.
CommonMark
Ces efforts, ainsi qu’un gros travail de John MacFarlane (l’auteur de Pandoc), ont permis d’arriver à un standard. Ce projet, initialement nommé « Standard Markdown », a dû être renommé en « CommonMark » suite à une réclamation de John Gruber, un des créateurs de Markdown. Il prend la forme d’une description très précise des règles à prendre en compte pour écrire un analyseur lexical Markdown. On pourrait regretter qu’il ne soit pas accompagné d’une grammaire formelle, mais il semblerait qu’il soit particulièrement difficile de faire cela (la plupart des analyseurs lexicaux travaillent en plusieurs passes). John MacFarlane a également écrit deux implémentations de références : l’une en C et l’autre en JavaScript.
Ce travail de rapprochement des implémentations n’est toutefois qu’une première étape. Les différentes implémentations ont toutes diverses extensions aux langages (tableaux, notes de bas de pages, etc.) avec des syntaxes souvent différentes pour la même fonctionnalité. Il reste donc du boulot à l’équipe de CommonMark pour prendre en compte ces extensions et répondre aux nombreuses discussions sur le forum Discourse du projet (qui d’ailleurs utilise une syntaxe Markdown qui n’est pas encore du CommonMark).
Particularités de LinuxFr.org par rapport au Markdown et CommonMark
Le Markdown gagnerait à évoluer et être standardisé pour prendre en compte les évolutions apportées de part et d’autre. Sur LinuxFr.org, les choix suivants ont été effectués :
- ajout d’une table des matières pour les articles longs ;
- liens vers le wiki interne avec la syntaxe
[[[wiki]]]; - gestion du
avec quelques incompréhensions de la syntaxe $\LaTeX$; - gestion en standard des images, mais il y a une évolution proposée pour les sons et vidéos ;
- non prise en compte des deux espaces en fin de ligne pour passer à la ligne (quasiment tout le monde a râlé là‐dessus) : CommonMark permet d’utiliser un antislash plutôt que deux espaces pour que ce soit visible, mais conserve le même mécanisme.
Amélioration possibles du Markdown de LinuxFr.org
- gestion plus fine par lettre (et non juste par mot) des enrichissements (gras, italique, barré et télétype).
Il resterait à identifier d’autres différences du Markdown sur LinuxFr.org et ce qui bénéficierait de la standardisation proposée par CommonMark.
Bibliothèques de développement utilisées pour le Markdown
Sur LinuxFr.org, spécifiquement, les bibliothèques suivantes sont utilisées pour gérer le Markdown :
- le rendu HTML de Markdown est effectué par RedCarpet ;
- il y a Pygments pour l’affichage du code : ```langage précédé d’une ligne blanche permet la coloration syntaxique (très utile dans les forums et commentaires ou en 2e partie de dépêche technique) ;
- c’est à SVGtex que vous devez le rendu des bouts de .
Autres points à discuter ?
Aller plus loin
- Article LWN sur Common Markdown (148 clics)
- CommonMark (336 clics)
- Forum de discussion de CommonMark (123 clics)
- Markdown tel que sur LinuxFr.org (168 clics)
- Entrées du suivi ouvertes sur LinuxFr.org pour le Markdown (54 clics)
# Chapeau pour le sang-froid
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Bravo aux auteurs de CommonMark pour leur sang-froid face à John Gruber, qui s'est visiblement comporté dans cette affaire comme un parfait goujat : à leur place, je crois que je me serais énervé, et que j'aurais perdu pas mal de temps et d'énergie pour arriver finalement au même résultat.
[^] # Re: Chapeau pour le sang-froid
Posté par feth . Évalué à 7.
N'aimant pas les conflits, je serais passé à sphinx et j'y aurais gagné un système un peu plus flexible, extensible et éprouvé, bien que délimité par une spécification.
[^] # Re: Chapeau pour le sang-froid
Posté par Stibb . Évalué à 7.
Tu veux dire reStructuredText. Sphinx défini des extensions (supporté en natif par le langage) pour la mise en page de documentation
[^] # Re: Chapeau pour le sang-froid
Posté par feth . Évalué à 2.
Oui. J'ai du mal à faire sans sphinx, mais il est bien possible que rst tout nu avec quelques extensions serait un meilleur choix pour un système interactif et public.
[^] # Re: Chapeau pour le sang-froid
Posté par Stibb . Évalué à 2.
oui je le pense également. Je n'aime pas la syntaxe markdown en general. Il y a quelques syntaxe en rst qui sont quand meme penible (les liens par ex)
[^] # Re: Chapeau pour le sang-froid
Posté par vpo . Évalué à 2. Dernière modification le 19 novembre 2014 à 11:46.
Certes, mais comme dit fort justement plus bas, John Gruber exige son accord écrit pour l'utilisation du mot Markdown pour autre chose que son propre bébé. On peut le regretter, mais c'est ainsi.
On peut éventuellement lui contester ce droit en rétorquant que markdown est un mot du dictionnaire. Mais les auteurs de CommonMark ne remettaient pas en cause cet état de fait. Dès lors, violer les conditions d'utilisation édictée par l'auteur d'origine en se disant "qui ne dit mot durant quelques jours consent" était pour le moins hasardeux, surtout si le mec est à cheval sur le principe voire procédurier…
[^] # Re: Chapeau pour le sang-froid
Posté par FantastIX . Évalué à 3.
S'il ne donne pas de réponse alors qu'on lui fait la demande? On continue d'attendre? On suspend le projet indéfiniment jusqu'à ce qu'il condescende à répondre? Si ce monsieur est à cheval sur "les principes", on peut déduire qu'il y en a sur lesquels il s'assied.
[^] # Re: Chapeau pour le sang-froid
Posté par vpo . Évalué à 2.
On prend un nom de projet qui n'exige pas son accord… comme cela a d'ailleurs été fait au final.
[^] # Re: Chapeau pour le sang-froid
Posté par laurentb (site web personnel) . Évalué à 1.
Malheureusement le seul autre fait d'arme de ce monsieur est d'être "bloggeur influent" (et accessoirement le plus grand fanboy Apple). L'erreur première a été le choix de Markdown par un certain nombre de sites, surement trop attirés parce qui est hype, alors qu'il n'était pourtant même pas le premier arrivé.
# Pas markdown
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Ça c'est juste une histoire de présentation, pas de syntaxe (puisqu'il suffit de répertorier tous les titres). Donc au final pas de rapport avec Markdown :-)
[^] # Re: Pas markdown
Posté par zurvan . Évalué à 4.
Non, mais d'autres systèmes, comme txt2tags, ont dans leurs implémentations la possibilité de générer une table des matières automatique (la macro c'est %%toc)
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Pas markdown
Posté par Anonyme . Évalué à 6.
Oui oui, je sais où est la sortie.
# table
Posté par ckiller . Évalué à 4.
j'ai toujours rêver d'écrire des vrais documents à base de fichier texte simple.
j'ai testé restructuredtext, markdown… mais j'ai toujours trouvé un obstacle, le formattage des tableaux complexe.
même avec les modes emacs spécialisés (moins pire),
donc, c'est sympa pour les commentaires web, mais sinon, c'est très décevant.
[^] # Re: table
Posté par Jiehong (site web personnel) . Évalué à 2.
Par mode d’Emacs spécialisé, tu parles de la gestion des tableaux sous org-mode ?
C'est souvent suffisant pour faire pas mal de choses (et ça manque terriblement sous markdown, tout comme les références). Qu’attends-tu par « tableaux complexes » ?
[^] # Re: table
Posté par Clément David (site web personnel) . Évalué à 2.
Personnellement j'utilise aussi markdown comme syntaxe de base de mes documents, pando avec ses extensions de markdown permet pour gérer beaucoup de cas particuliers. De plus on peux facilement utiliser de templates pour générer des documents propres.
Pour les tableaux, plusieurs syntaxes sont supportées http://johnmacfarlane.net/pandoc/README.html#tables cependant je suis d'accord que si tu veux faire du merge de cellule ça ne me semble pas possible en markdown directement.
Est-ce que tu pourrais décrire ce que tu souhaites faire comme mise en page ?
[^] # Re: table
Posté par ckiller . Évalué à 1.
Par exmeple, des tableaux comme cela, fusion de cellules, du multi-ligue…
[^] # Re: table
Posté par Jiehong (site web personnel) . Évalué à 3.
Dans cet exemple, il manque une chose aux tables d'org : le multilignes, bien que le multi-colonnes soit bien présent.
Sinon, l'emphase, la limite de taille, la justification (centre, droite ou gauche), et même un peu de calcul est pris en charge très simplement.
[^] # Re: table
Posté par nud . Évalué à 3.
Fais du LaTeX ?
Sinon, tant avec Markdown qu'avec reST il est possible d'inclure directement du HTML, pour les cas compliqués de ce style.
[^] # Re: table
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 2.
Le problème d'inclure du LaTeX comme du HTML c'est que tu perds un des intérêts du markdown (pour moi en tout cas) qui est de pouvoir générer plusieurs formats de sorties différents à partir du même fichier de départ.
[^] # Re: table
Posté par zurvan . Évalué à 2.
Le problème aussi c'est qu'à part du html (et encore, avec des tonnes de CSS, cf. le texte écrit à la verticale) ou du LaTeX, il n'y a pas beaucoup de syntaxes qui vont pouvoir gérer un tableau aussi complexe (et la source sera difficilement lisible je pense, à part pouvoir l'écrire direct en ascii art et que ça soit bien interprété, ditaa le fait bien…). Pour des diagrammes complexes j'utilise inkscape ou graphviz, on ne peut pas non plus tout faire avec un seul outil.
Si le reste du document est plus simple, et le système de langage de balisage pas trop mal fait, il est possible d'inclure dans la source la version html et la version LaTeX du tableau, et de sélectionner la version voulue lors de la génération finale du document (en html ou LaTeX).
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: table
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Et pour les formules mathématiques, le LaTeX est indispensable… Personnellement, cela devrait être intégré dans le HTML ;-) La syntaxe MathML ne sera jamais utilisé par un être humain !
On peut s'amuser à réinventer un système humain pour écrire des équations mais il faut être honnête, le LaTeX est franchement pas mal pour cela…
[^] # Re: table
Posté par feth . Évalué à 2.
En sphinx/rst, en utilisant un fichier csv pour le tableau :
[^] # Re: table
Posté par yannick.copin . Évalué à 1.
docutils/reStructuredText supporte ce genre de table complexe via les grid tables. Je n'ai pas testé explicitement, mais ce doit donc être supporté par Sphinx.
Et pour éditer ce genre de table complexe, on peut utiliser le table mode de Emacs (fourni par défaut pour les version >= 22)
[^] # Re: table
Posté par Rémi PALANCHER (site web personnel) . Évalué à 4.
Si par « tableaux complexes » tu entends rowspan, colspan, liste dans les cellules, etc… C'est spécifiquement la raison pour laquelle j'utilise la syntaxe asciidoc ! Avec son implémentation de référence en Python, ou son excellente alternative asciidoctor en Ruby.
Ce n'est pas du markdown (donc un HS par rapport à la dépêche) mais c'est la syntaxe la plus complète à ma connaissance.
[^] # Re: table
Posté par Ignatz Ledebur . Évalué à 2.
Le soucis, c'est que dès que tu as plusieurs colonnes, tu es obligé d'abstraire, ce qui rompt le « contrat » de ce genre de syntaxe, à savoir la proximité des rendus source/généré. On ne peut en effet pas maintenir dans un éditeur un texte sur plus d'une colonne, ce qui amène naturellement n'importe quel concepteur de langage un tant soit peu sensé à l'implémenter sous forme d'instruction, genre « multicols=2 », ce qui renoue sans en avoir l'air avec le balisage classique. Donc, ça n'est pas très étonnant qu'avec les tableaux ça finisse toujours en pâtée ou dans l'ultra-limité.
Personnellement, je suis en train de revenir au HTML, d'une part parce que dès qu'une syntaxe se voulant facile prend de l'ampleur, j'ai l'impression d'assister à sa réinvention, et d'autre part parce qu'une fois qu'on a éliminé d'une page tout le code lié à la navigation, on s'aperçoit que pour le texte ordinaire, le seul pour lequel les syntaxes mardown tiennent toutes leurs promesses, il y a finalement très peu à écrire, même en XHTML.
[^] # Re: table
Posté par zurvan . Évalué à 2.
Je suis d'accord, les tableaux, c'est un peu la galère, et un tableau complexe sera illisible écrit dans une syntaxe légère (cf. les tableaux de wikipedia). Néanmoins ça dépanne lorsqu'on a surtout des tableaux simples.
Txt2tags permet quelques possibilités, @ckiller est-ce que tes besoins les dépassent ?
http://txt2tags.org/rules.html#table
(la source est ici : https://code.google.com/p/txt2tags/source/browse/trunk/test/table/table.t2t)
D'autre part, il est possible de rajouter facilement (avec le préprocesseur qui utilise des regex) une syntaxe personnalité, et le format de sortie souhaité.
Enfin, on peut aussi inclure du html ou du LaTeX brut, ce qui permet de finalement faire tout ce qu'on veut.
J'écris tous mes documents avec ce système.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: table
Posté par Ignatz Ledebur . Évalué à 6.
Le problème, c'est que tu ne peux jamais connaître tes besoins a priori.
Par exemple, j'ai pendant des années développé ma propre syntaxe de style markdown, avec laquelle j'ai rédigé l'ensemble de mes documents (pages de manuels et notes, pages HTML, et même des recettes de cuisine). J'avais fait les choses bien, comme séparer sous forme le modules Perl l'analyseur du source d'avec les traducteurs vers les différentes sorties, et prévoir un mécanisme d'échappement qui permettait de traiter certains blocs comme on le voulait depuis le script de l'utilisateur (pas seulement avec des regex, mais avec toute la syntaxe Perl, donc).
Quand j'ai amorcé le projet, je me suis dit que je n'aurai jamais besoin de gérer les notes en bas de page, car je ne fais pas de travaux universitaires et c'est un procédé que je n'aime pas beaucoup. La suite m'a démontré que j'avais raison, car jamais les documents que j'ai rédigés n'ont appelé pareilles notes. Seulement voilà, un jour j'ai eu l'idée d'« éditer » un texte tiers qui lui en comprenait, et là ça a été tellement la galère intégrale pour intégrer la chose proprement (il fallait que les notes puissent utiliser l'ensemble de la syntaxe, pas seulement des paragraphes) que ça m'a dégoûté (bon, sans doute aussi avais-je un peu perdu le feu sacré, mais ça n'aurait pas été mieux si j'avais eu à gérer un tas hétéroclite de regex ad hoc).
C'est là que je me suis souvenu que lors de mes débuts sur le oueb, on écrivait encore le HTML à la main et que tout novice que j'étais ça ne m'avait jamais semblé insurmontable, peut-être un peu moins confortable que la syntaxe wiki qui a émergé après, mais pas fondamentalement différent (le wiki ne m'a jamais paru révolutionnaire d'un point de vue strictement syntaxique). J'ai alors réalisé que si je l'avais adopté en tant que format source au lieu de me laisser appâter par la facilité relative de la syntaxe wiki (qui est au fond une formalisation étendue de la syntaxe courante du courriel) j'aurais eu quelque chose de pas plus difficile à analyser (le XHTML 1.0 n'est jamais qu'une pile de balises dont l'empilement est cadré par de doctype) tout en étant nettement plus souple, complet, éprouvé, et surtout directement utilisable. Car après tout, le HTML est un format voire le format de sortie pour toute syntaxe de type markdown (les autres sont souvent conçus comme des formats d'archivage secondaires), d'où il n'est pas idiot de conclure que tout ce que peuvent ces syntaxes est nécessairement représentable en HTML.
[^] # Re: table
Posté par FantastIX . Évalué à 6.
C'est pas faux mais je crois comprendre que ce qui pique les yeux dans HTML, c'est le caractère verbeux des balises, ce qui le rend vite indigeste. L'avantage des syntaxes "à la Wiki" c'est que les symboles passent mieux que les mots en tant que délimiteurs. C'est seulement quand on commence à avoir autant de marqueurs que de mots que ça devient aussi indigeste de toutes façons. J'ai l'impression que c'est insoluble comme problème ou, en tout cas, qu'il n'y a pas de solution élégante sinon on l'aurait déjà trouvée et généralisée, je me trompe?
[^] # Re: table
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Il y a le même problème en mathématiques. :p
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: table
Posté par wilk . Évalué à 1. Dernière modification le 21 novembre 2014 à 09:01.
D'où l'intérêt de textile la syntaxe est très proche du html/css.
[^] # Re: table
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Moué non, le Textile a des trucs assez bien pensé, comme le fait de baliser les titres avec
h1.,h2.,h3.etc.Bon, ça ressemble tout de suite à du code à la différence de markdown, mais c’est concis et ça supporte de multiples niveaux, à la différence de markdown (combien de niveau en soulignement ? deux ?, et multipliant les
#ça peut devenir compliqué s’il y a beaucoup de niveaux).Par contre en textile il y a d’énormes défauts qui me font préférer Markdown.
Les urls sous la forme "texte":chemin , que se passe-t-il quand l’url termine par un point ? Pour cette raisons, à chaque fois que je dois écrire du textile et que je veux mettre un point après une url je laisse une espace disgracieuse parce que je ne sais pas quel sera le comportement, et si le moteur textile ne permet pas de placer un point en fin d’url, c’est qu’il est défectueux.
La balise image ne permet pas d’écrire un texte alternatif en Textile, le Markdown si. Le Markdown est donc lisible en mode texte de manière interprétée ou non interprété, même sans affichage des images. Le Markdown est plus adapté à l’export HTML que le Textile. Le Textile n’est pas exportable vers l’XHTML qui requière l’attribut
alt.Et il y a peut-être d’autres problèmes auxquels je ne pense pas, j’évite le Textile autant que possible à cause de ces trois problèmes.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: table
Posté par Ignatz Ledebur . Évalué à 2. Dernière modification le 21 novembre 2014 à 14:32.
En fait, pour tout ce qui syntaxe commune (paragraphe, italique, gras), pas tant que ça parce que les balises sont courtes. Ça devient un peu plus chaud avec les listes imbriquées, mais ce n'est pas la mort non plus parce que c'est rare d'avoir au-delà de deux ou trois niveaux. Le vrai soucis, c'est le code, qui est d'ailleurs ce qui m'a poussé à faire ma syntaxe, me permettant d'écrire :
Au lieu de :
Il n'y a pas photo en terme de simplicité, et ça a fait ma joie pour les pages de manuels. La seule réserve qu'aujourd'hui je ferais, c'est que c'est utile principalement pour la rédaction. Quand on a quinze séquences comme ça à se taper, c'est à se tirer une balle, mais une fois le document rédigé, les retouches sont toujours plus limitées et l'intérêt s'estompe (même si tu passes 5min sur une séquence pénible, tu n'as pas le temps d'atteindre le point de saturation).
Si j'avais à me replonger dans ce genre de choses, c'est donc très certainement autour de cette temporalité que je travaillerais, afin élaborer un ou des outils permettant d'obtenir une aide ponctuelle. Mais bon, pour ce qui est de mon environnement, je confesse que plus ça va et plus je deviens une sorte de Kaurismäki de l'informatique ; pas sûr que l'utilisateur moderne trouve ça pratique, et encore moins élégant. :)
[^] # Re: table
Posté par barmic . Évalué à 4.
C'est pour ça que les derniers documents que j'ai rédigés from scratch c'est une syntaxe markup, pour l'écriture initiale, puis génération d'un
.texsi je suis seul dessus, sinon html et je fais la mise en page dans ce dernier format, mais une fois que je suis dans ce second format je bazarde la source.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: table
Posté par Ignatz Ledebur . Évalué à 1.
Oui, c'est à un truc comme ça que je pensais, mais avec en plus la possibilité de travailler sur un document généré. Par exemple dans du HTML, tu signalerais entre deux
<!>le passage où il faut interpréter le markdown, et pof ! l'outil ne traiterait que celui-ci.En standalone, ça ne doit pas être bien compliqué à mettre en œuvre, mais pour ce qui est de l'intégration avec l'éditeur…
[^] # Re: table
Posté par barmic . Évalué à 4.
J'ai plus l'habitude de faire l'inverse avec txt2tags (le document est en t2t et il contient des parties dans d'autres langages).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: table
Posté par Ignatz Ledebur . Évalué à 1.
Oui mais là on retomberait dans ce qu'on veut éviter, puisqu'il faudrait toujours t2t pour générer le HTML final. Dans mon idée, une fois la commande passée, il ne reste que du source HTML (d'où le problème de l'intégration avec l'éditeur, pour pouvoir éventuellement revenir en arrière).
[^] # Re: table
Posté par Stéphane Aulery (site web personnel) . Évalué à 2.
Brian Reid, l’auteur de Scribe l’un des premiers langages de markup, a abordé ce problème lors d'une keynote au Markup Technologies '98 Conference (1998) : 20 years of abstract markup Any progress?. Il manque les notes pour accompagné le support de présentation. Dommage, j'aurais aimé en savoir un peu plus.
SA
[^] # Re: table
Posté par ckiller . Évalué à 1.
c'est intéressant, mais quand j'avais essayé ce genre de truc, le multiligne était la galère, et ca ne compilait jamais comme je voulais
[^] # Re: table
Posté par zurvan . Évalué à 1.
txt2tags a introduit un préprocesseur spécial (postvoodoo), qui fonctionne sur du multiligne, au lieu de ligne par ligne comme d'habitude, par exemple :
%!postvoodoo: '(.*?)\n=[=*]{2,}=' '<h1>\1</h1>'
permettra de générer une balise html H1 lorsqu'il rencontre un titre markdown (du texte souligné à la ligne en-dessous)
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# J'aime pas markdown
Posté par barmic . Évalué à 7.
Perso je n'aime pas markdown, j'en écris parce que je suis bien obligé, mais il n'a pas la syntaxe la plus agréable et reste assez pauvre de base. Pour moi c'est vraiment le markup du pauvre. Au lieu d'en décrire un ensemble pour tenter de le standardiser, pourquoi ne pas partir sur un format bien foutu comme creole, restructuredtext, pod ou txt2tags ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'aime pas markdown
Posté par romu . Évalué à 3.
…ou textile, que je trouve assez bien fait pour ma part.
[^] # Re: J'aime pas markdown
Posté par zurvan . Évalué à 2.
moi non plus je n'aime pas markdown, c'est vrai que c'est limité.
Pour le côté agréable de la syntaxe, ça reste subjectif bien entendu.
Creole a eut une démarche intéressante, en étudiant différentes syntaxes utilisées :
http://www.wikicreole.org/wiki/Reasoning
fait amusant, la plupart des marques utilisées ressemblent à txt2tags (qui existe depuis 2001). Par contre ils n'en parlent pas dans leur étude.
L'avantage de txt2tags c'est que l'on peut rajouter, modifier de la syntaxe, comme ça on n'est jamais bloqué.
Par exemple avec une quinzaine de lignes de regex, je peux rajouter dans txt2tags la plupart des marques de markdown :
https://raw.githubusercontent.com/farvardin/whatistxt2tags/master/whatistxt2tags.t2t
Tous les efforts d'uniformisation vers une « syntaxe ultime » n'aboutiront jamais, car un développeur web ou C++ n'a pas les mêmes besoins qu'un écrivain de romans, ou qu'un chercheur en science humaine.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Le choix du nom
Posté par reynum (site web personnel) . Évalué à 4.
il y avait une proposition pour :
Franchement je ne comprend pas pourquoi un nom si génial n'a pas été retenu cela n'aurait peut être pas énervé John Gruber ? :-D
kentoc'h mervel eget bezan saotred
[^] # Re: Le choix du nom
Posté par grim7reaper . Évalué à 1.
Pas sûr, vu que c’est l’usage du mot Markdown qui semble lui poser problème.
Et comme le dit la licence :
[^] # Re: Le choix du nom
Posté par barmic . Évalué à 4.
Donc
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le choix du nom
Posté par anaseto . Évalué à 3.
Si c'est un autre implémentation, ou même pas un logiciel (juste une spécification), c'est quand même un produit dérivé du logiciel d'origine ? J'aurais pensé que non. D'ailleurs, si on considère que c'est le cas, ils devraient aussi enlever toute mention du nom de John Gruber dans la spécification… après tout, quelqu'un de tordu pourrait penser qu'ils l'utilisent pour promouvoir leur produit, et pas juste par politesse envers l'inventeur d'origine.
[^] # Re: Le choix du nom
Posté par zurvan . Évalué à 10.
intéressant. Donc d'après ce qui est marqué dans cette licence :
j'ai le droit de créer un logiciel de toute pièce, avec une syntaxe concurrente, ou dans un autre créneau, qui s'appelle "Markdown".
J'ai le droit de créer une des 1000 implémentations possible de markdown (donc un nouveau logiciel), en ruby, en python, en brainfuck, en js, et l'appeler Markdown (ce qui s'est passé)
à la rigueur, j'ai le droit de faire une version dérivée de la syntaxe markdown (ce qu'a fait CommonMark), dans un autre logiciel n'utilisant pas de code du markdown originel), et continuer à l'appeler Common Markdown ou Markdown.
Il s'embête pas trop Gruber, il a pondu son truc en 2004 et n'y a pas retouché depuis, ceux qui ont souhaité standardiser markdown l'on contacté, lui on demandé si ça lui allait que ce travail soit fait, il n'a pas daigné répondre, et 1 ou 2 ans plus tard, il vient mettre son droit de veto (alors qu'il n'a rien dit pour les "markdown extra", "github flavored markdown" et compagnie).
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# pourquoi Markdown
Posté par BAud (site web personnel) . Évalué à 7.
Heureusement que txt2tags a été évoqué ;-)
C'était le 3è choix proposé lors de l'alpha de LinuxFr.org à l'occasion du passage en Ruby.
Nous avions voté entre modérateurs à l'époque (je ne me rappelle plus si cela a été proposé aux participants à LinuxFr.org, ne serait-ce qu'au travers d'un sondage, sans aller jusqu'à une dépêche :/).
Forcément, en tant qu'adepte des wiki cela remplaçait avantageusement le pseudo langage HTML qui nous était possible (mais peu utilisé, ni facilement maîtrisable, ni mis en avant). Et en plus avec la nouvelle version de LinuxFr.org on aurait un wiki ! (j'étais super-content, je vous rassure, je n'ai pas vomi partout).
Les deux choix principaux ont été :
Je ne connaissais pas Markdown, mais j'ai voté "pas Mediawiki" pitié, les liens sont trop compliqués, les listes aussi et l'italique/gras sont inutilement non intuitifs (Markdown est à peine mieux, mais moins pire en y regardant).
Je suis bien content que Markdown a été choisi à l'époque : il est désormais bien utilisé, avec des utilisations avancées d'ailleurs (oui, je pense à CrEv< et sa veille technologique, avec tous les liens documentés, comme dans une biblio).
j< forcément, avait tenté de promouvoir txt2tags, le manque de bibliothèque Ruby pour le gérer à l'époque (ou les doutes) ont fait qu'il n'a pas été retenu (ou vraiment regardé).
Bref. Vive Markdown ! ;-) (et la foule de se lever comme pour un touchdown !)
Néanmoins, je constate avec regret qu'il n'y a pas de nouvelle entrée de suivi pour améliorer l'interaction dans les commentaires sur LinuxFr.org ni de commentaires sur les entrées de suivi (la balise vidéo devrait motiver du monde tout de même ? NoNo< propose aussi d'autres éditeurs).
Il y a aussi peu d'éditions du wiki notamment pour préciser et compléter la page aide-édition.
Il y avait plus de monde pour râler sur la non-nécessité de deux espaces en fin de ligne pour passer à un paragraphe suivant (ne pas le faire mettait tout sur la même ligne, comme sur slashdot…).
Que faut-il pour devenir utilis'acteur ? (je laisse créer la page :p)
Merci aux intervenants d'avoir confirmé que la syntaxe retenue sur LinuxFr.org remplit son rôle et est relativement utilisable pour tout le monde, ça c'est un point très positif pour le choix de Markdown en tout cas ! (bon pour les tableaux, cela ne sert que ponctuellement, une mise à jour des CSS les mettrait sans doute en valeur même si cela reste l'utilisation la plus casse-tête en édition :/).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.