Peut-être qu'un jour un contributeur zélé réécrira txt2tags en go !
Peut-être :) Ceci dit, c'est pas sûr que le système d'extension par substitutions deviendrait rapide pour autant : outre des questions de langages, c'est le principe en soi qui est problématique, les expressions régulières de Go sont pas plus rapides que celles de Python. Mais je t'accorde que c'est pas du tout ce qui m'a fait écrire frundis qui, au début, a servi à remplacer pandoc et la question de la performance m'était même pas venue à l'esprit et, pourtant, c'était bien plus lent que txt2tags ;) (qui au fond, vu son fonctionnement, est relativement rapide).
Et mes ePUB générés par ce biais seront sans doute plus propre qu'une bonne partie des ePUB commerciaux qui font souvent n'importe quoi.
C'est bien possible, j'avoue ne pas avoir réussi à produire de l'EPUB valide du premier coup, ni du deuxième :) Mais vu que l'EPUB, c'était quand même le format le plus important pour frundis, je voulais pouvoir contrôler le truc et pas dépendre d'un outil tiers comme Calibre ; remarque en passant, Calibre garantit que l'EPUB est correct uniquement si le XHTML source l'est, il faut donc quand même vérifier avec epubcheck après.
Sans doute qu'un script qui analyserait plus finement le texte pour souligner expressément tout ce qui lui semble hors norme.
C'est un peu comme les langages de programmation, d'un côté ceux qui offrent des garanties à la compilation et puis les autres qui se contentent d'heuristiques, donc effectivement, il est un peu question de sensibilité :) Mon impression, c'est que c'est un peu plus dur de tester automatiquement des textes que du code, mais j'avoue ne pas m'être penché sur la question sérieusement ; j'ai bien quelques scripts vite-faits pour détecter des trucs suspects que frundis détecterait pas lui-même —scripts qui ont bénéficié du fait que le langage soit facile à parser—, mais c'est tout.
[^] # Re: roue.com
Posté par anaseto . En réponse au journal frundis : un langage de balisage sémantique qui mûrit !. Évalué à 2.
Peut-être :) Ceci dit, c'est pas sûr que le système d'extension par substitutions deviendrait rapide pour autant : outre des questions de langages, c'est le principe en soi qui est problématique, les expressions régulières de Go sont pas plus rapides que celles de Python. Mais je t'accorde que c'est pas du tout ce qui m'a fait écrire frundis qui, au début, a servi à remplacer pandoc et la question de la performance m'était même pas venue à l'esprit et, pourtant, c'était bien plus lent que txt2tags ;) (qui au fond, vu son fonctionnement, est relativement rapide).
C'est bien possible, j'avoue ne pas avoir réussi à produire de l'EPUB valide du premier coup, ni du deuxième :) Mais vu que l'EPUB, c'était quand même le format le plus important pour frundis, je voulais pouvoir contrôler le truc et pas dépendre d'un outil tiers comme Calibre ; remarque en passant, Calibre garantit que l'EPUB est correct uniquement si le XHTML source l'est, il faut donc quand même vérifier avec epubcheck après.
C'est un peu comme les langages de programmation, d'un côté ceux qui offrent des garanties à la compilation et puis les autres qui se contentent d'heuristiques, donc effectivement, il est un peu question de sensibilité :) Mon impression, c'est que c'est un peu plus dur de tester automatiquement des textes que du code, mais j'avoue ne pas m'être penché sur la question sérieusement ; j'ai bien quelques scripts vite-faits pour détecter des trucs suspects que frundis détecterait pas lui-même —scripts qui ont bénéficié du fait que le langage soit facile à parser—, mais c'est tout.