• [^] # Re: roue.com

    Posté par . En réponse au journal frundis : un langage de balisage sémantique qui mûrit !. Évalué à 10.

    Question classique en effet :) Et pas forcément facile, tellement il y a d'arguments d'ordres différents, allant du technique au subjectif et parfois les deux en même temps, un peu comme pour les langages de programmation !

    Ceci dit, un point de départ pour comprendre les spécificités de frundis, c'est qu'initialement l'objectif étant de pouvoir exporter des romans à la fois en LaTeX et EPUB, il fallait surtout ceci :

    • Des tags sémantiques spécifiques à un projet : DocBook est très centré documentation uniquement ; là il fallait pouvoir définir facilement des tags pour nom de lieu, pensée, nom de plante, etc. Pas forcément beaucoup d'éléments sémantiques pour un document donné, mais pas évidents à prévoir. Du coup, en frundis on écrit une espèce de feuille de style simplifiée pour chaque format d'export.
    • J'avais par contre besoin aussi de poèmes, et DocBook faisait pas ça la dernière fois que j'ai regardé.
    • Personaliser facilement et finement les exports LaTeX et EPUB, c'est-à-dire pouvoir donner soi-même facilement des commandes pour un préambule LaTeX ou les fichiers d'en-tête EPUB au besoin, tout en fournissant des trucs raisonnables par défaut également. Pour le coup, je sais pas si avec asciidoc/DocBook on peut faire ça, peut-être, pas vérifié vu qu'il manquait d'autres trucs.
    • Macros textuelles et variables, surtout pour éviter certaines redites, partager et structurer des choses entre divers documents ; mais macros limitées : pas de macros qui définissent des macros ou d'autres horreurs du style, parce que ça rend moins accessibles les messages d'erreurs et le langage en soi ; bon, « horreur », c'est relatif, mais pour mes utilisateurs actuels ça le serait :)

    Et puis, arguments techniques ou subjectifs, ou les deux, je sais pas :

    • Langage simple. Au sens, la documentation complète doit être accessible (donc aussi suffisamment courte) à quelqu'un qui connait un peu LaTeX et HTML, mais ne sait pas forcément programmer ni a de connaissances techniques poussées. Il ne faut donc pas que le langage définisse des éléments spécifiques de base : à chacun de définir ceux dont il a besoin pour son projet ; du coup, ça veut dire que ça doit être facile à faire, sinon c'est raté.
    • Gestion des erreurs de syntaxe intuitive, rapide et qui nous protège d'erreurs non intentionnelles. Il s'agissait donc un peu de la philosophie opposée à markdown, où tout fichier texte est valide : avec frundis il s'agit d'avoir des garanties que les éléments sont correctement fermés, etc., pas de typos qui gâche un paragraphe sans faire exprès : vérifier un texte court, ça va, mais vérifier tout un roman à la main, ça fait un peu plus peur ;)
    • Rapide : utile pour refaire tous les fichiers HTML d'une page web et avoir un retour immédiat. Aussi quand on exporte vers LaTeX : on a les messages d'erreurs avant, ça évite d'essayer de compiler avec LaTeX quand c'est perdu d'avance parce que frundis à râlé ; enfin, frundis fait de son mieux pour corriger et produire des trucs corrects même quand le fichier source ne l'est pas.
    • Facile à installer : pas de dépendances (je me répète un peu avec le journal).
    • Documenté avec le langage mdoc pour faire des pages man que j'adore ! (d'ailleurs on sent un tout petit peu l'influence dans frundis...)

    ...Et puis sans doute d'autres trucs auxquels je pense pas de suite, moins importants ou que je sais pas comment dire.