Toutes, toutes, j'ai pas l'impression, au point que je sais pas par où commencer :)
Déjà, j'ai écrit le fichier suivant (avec des espaces au début pour les headers) :
=Title=
=Title==
A test file with //emphasis.
A test file with //emphasis/.
A test file with /emphasis//.
Eh bien, j'ai aucun message d'erreur. Tout est correct ! Le premier titre apparaît balisé, le deuxième apparaît tel quel avec les signes =, et dans le texte on a les / tels quels. Même sans imaginer le cas où on utilise plusieurs fois de l'emphase dans un même paragraphe... on est pas sortis de l'auberge pour trouver des erreurs dans un gros document !
Et puis, les extensions du langage, c'est à coup de substitutions... pas étonnant aussi, le langage est implémenté à coup d'expressions régulières ;) Mais ça ne fait que accentuer cette impression qu'on peut pas faire trop confiance au résultat et qu'il faut tout vérifier à la main à chaque changement. Et d'ailleurs, pas étonnant du coup non plus que ça rame un peu. Pour un fichier avec seulement A test file with //emphasis//. répété cent mille fois, c'est 7 secondes, là où pour la même chose frundis fait une demi-seconde ; et il y a des chances que si on se met à utiliser ses propres substitutions par dessus le langage de base, ça ne fasse qu'empirer.
Ceci dit, je suis d'accord qu'il y a des trucs positifs par rapport au markdown, comme pouvoir inclure des fichiers facilement et le fait qu'il n'y a qu'une seule implémentation, donc une seule variante du langage. On dirait que c'est ok aussi niveau dépendances. Mais ça reste un langage « léger », c'est-à-dire un monde à part optimisé pour des usages différents, avec les avantages, mais aussi les inconvénients qui vont avec. Ceux qui me tiennent particulièrement à cœur sont l'absence de messages d'erreurs et la grammaire compliquée et irrégulière ; il en découle aussi qu'en l'absence d'un langage plus formel on se retrouve à inventer des syntaxes ad hoc pour les extensions et la configuration, qui ne simplifient pas spécialement le langage. Enfin, aussi, il y a le coté très « forme mélangée avec le fond » : dans les éléments de balisage par défaut du langage, la plupart s'intéressent à la forme (gras, italique, etc.), ils ne sont pas sémantiques, ça n'encourage pas ni n'aide à faire des documents cohérents d'un point de vue balisage.
PS: j'ai pas vu d'export EPUB, donc je suppose qu'il faudrait d'abord exporter vers autre chose puis utiliser un deuxième outil. Un peu étonnant, parce que quand on sait faire de l'html, il n'y a plus grand chose à faire pour produire de l'EPUB.
[^] # Re: roue.com
Posté par anaseto . En réponse au journal frundis : un langage de balisage sémantique qui mûrit !. Évalué à 2.
Toutes, toutes, j'ai pas l'impression, au point que je sais pas par où commencer :)
Déjà, j'ai écrit le fichier suivant (avec des espaces au début pour les headers) :
Eh bien, j'ai aucun message d'erreur. Tout est correct ! Le premier titre apparaît balisé, le deuxième apparaît tel quel avec les signes
=, et dans le texte on a les/tels quels. Même sans imaginer le cas où on utilise plusieurs fois de l'emphase dans un même paragraphe... on est pas sortis de l'auberge pour trouver des erreurs dans un gros document !Et puis, les extensions du langage, c'est à coup de substitutions... pas étonnant aussi, le langage est implémenté à coup d'expressions régulières ;) Mais ça ne fait que accentuer cette impression qu'on peut pas faire trop confiance au résultat et qu'il faut tout vérifier à la main à chaque changement. Et d'ailleurs, pas étonnant du coup non plus que ça rame un peu. Pour un fichier avec seulement
A test file with //emphasis//.répété cent mille fois, c'est 7 secondes, là où pour la même chosefrundisfait une demi-seconde ; et il y a des chances que si on se met à utiliser ses propres substitutions par dessus le langage de base, ça ne fasse qu'empirer.Ceci dit, je suis d'accord qu'il y a des trucs positifs par rapport au markdown, comme pouvoir inclure des fichiers facilement et le fait qu'il n'y a qu'une seule implémentation, donc une seule variante du langage. On dirait que c'est ok aussi niveau dépendances. Mais ça reste un langage « léger », c'est-à-dire un monde à part optimisé pour des usages différents, avec les avantages, mais aussi les inconvénients qui vont avec. Ceux qui me tiennent particulièrement à cœur sont l'absence de messages d'erreurs et la grammaire compliquée et irrégulière ; il en découle aussi qu'en l'absence d'un langage plus formel on se retrouve à inventer des syntaxes ad hoc pour les extensions et la configuration, qui ne simplifient pas spécialement le langage. Enfin, aussi, il y a le coté très « forme mélangée avec le fond » : dans les éléments de balisage par défaut du langage, la plupart s'intéressent à la forme (gras, italique, etc.), ils ne sont pas sémantiques, ça n'encourage pas ni n'aide à faire des documents cohérents d'un point de vue balisage.
PS: j'ai pas vu d'export EPUB, donc je suppose qu'il faudrait d'abord exporter vers autre chose puis utiliser un deuxième outil. Un peu étonnant, parce que quand on sait faire de l'html, il n'y a plus grand chose à faire pour produire de l'EPUB.