Posts Tagged ‘Txt2tags’

Arrêtez d’écrire des classes !

Monday, December 30th, 2013

En créant les nouvelles fonctionnalités ASCII art de txt2tags, j’ai été amené à développer un certain nombre de fonctions spécifiques que j’ai donc logiquement fini par extraire dans une librairie autonome nommée aa.py. Pour des raisons historiques, d’habitude des utilisateurs et de facilité de diffusion, Aurélio Jargas – le BDFL de txt2tags – m’a demandé de réintégrer ces fonctions dans le fichier principal, ce à quoi il a ajouté :

Aurélio: move them back to global functions or creating a aa class in txt2tags?
option 2 would be cool

J’ai réfléchi, puis j’ai réintégré mes fonctions, telles quelles, sans créer de classe aa. Créer une classe dans ce cas ne me semblait pas adapté, complexifiant le code sans raison théorique valable ni contrepartie pratique positive.

Peu de temps après, je suis tombé sur une présentation intitulée Stop Writing Classes faite par le core developer Python Jack Diederich lors du PyCon 2012. J’y ai retrouvé beaucoup de choses que je pensais et d’autres que je n’avais pas encore clairement formalisées. Elle est particulièrement intéressante car elle utilise de vrais exemples de code, dont une horreur produite par des ingénieurs de chez Google !

On pourrait résumer cette réflexion avec les deux principes les plus importants de la programmation selon moi : KISS (Keep It Simple, Stupid) et DRY (Don’t Repeat Yourself). On peut remarquer que ce qui est pertinemment décrit comme une mauvaise utilisation des classes, correspond globalement à un style de programmation à la Java. Pour ceux qui ne comprendraient pas l’anglais et pour les gens pressés, voici donc les principales recommandations à retenir :

  • Diminuer le nombre de classes en refactorisant le code ;
  • Ne pas écrire de classes vides, qui pourraient être utiles plus tard, en utilisant pass, les écrire plus tard si besoin ;
  • Si une classe n’a que deux méthodes, et que l’une d’elle est __init__, c’est que ce ne devrait pas être une classe ;
  • Quand un dictionnaire suffit, ne pas le camoufler dans une classe ;
  • Ne pas créer de nouvelles exceptions, utiliser celles de la librairie standard, qui sont connues et comprises de tous ;
  • Les espaces de noms existent pour éviter les collisions, pas pour faire de la taxinomie, il faut donc qu’ils restent le plus plat possible.

Je finis en donnant la parole à la défense, avec cet article technique d’Armin Ronacher intitulé Start Writing More Classes.

Comparaison des langages de balisage (markup) léger (lightweight) : Txt2tags, Pandoc, Docutils, AsciiDoc, Deplate, Stx2any, AFT, Markdown et Textile

Sunday, August 14th, 2011

La bureautique est la principale utilisation de l’informatique depuis sa création. Pourtant, les outils majoritairement utilisés dans ce domaine, les logiciels de traitement de texte WYSIWYG comme LibreOffice et OpenOffice, laissent la majorité des informaticiens et des ergonomes très dubitatifs, voire totalement désespérés.

Ces logiciels ont en effet un nombre de défauts très important : ils font se concentrer sur la forme et non sur le fond, leur résultat final ne correspond souvent pas à ce qui est affiché, ils sont incompatibles entre eux, ce sont d’énormes usines à gaz inutilisables sur de vieilles machines, ils ne fonctionnent qu’en mode graphique, etc. La seule manière rationnelle, efficace et interopérable de travailler sur un ordinateur est d’utiliser de simples fichiers textes, tous les documents étant donc modifiable dans n’importe quel éditeur de texte.

Il a donc fallu penser à une manière de donner ces instructions de mise en forme au sein du fichier texte lui-même, et c’est ainsi que sont apparus les langages de balisage (markup), dont les plus connus sont HTML (inventé en 1991 par Tim Berners-Lee) et LaTeX (créé en 1985, et basé sur TeX, inventé par le grand Donald Knuth en 1977), et dont la première grande figure fut Roff, un programme Unix historique développé à partir de 1961, et dont la version GNU, Groff, est installée par défaut sur toutes les distributions Linux, puisqu’on l’utilise encore pour les pages de man des logiciels.

Pour mieux visualiser, prenons comme exemple la création d’une nouvelle section d’un document en man :

.SH Nouvelle section en man

en HTML :

<h1>Nouvelle section en HTML</h1>

et en LaTeX :

\section{Nouvelle section en LaTeX}

Ces langages représentent une nette amélioration, mais ont tous un gros problème : ils sont gênants ! On ne retrouve plus aussi facilement son contenu au milieu de toutes ces balises supplémentaires, sans parler du fait que les syntaxes complexes ouvrent la voie à de nombreuses erreurs de compilation.

C’est en 1995 que l’on trouva la solution de ce problème, avec la création du premier langage Wiki, dont le but principal était de permettre l’édition facile de pages web par tout un chacun, et dont l’utilisateur actuel le plus célèbre est l’encyclopédie libre Wikipédia. S’il y a presque autant de syntaxes différentes que de logiciels Wiki, elles ont toutes la caractéristique d’utiliser des caractères textuels simples et intuitifs pour donner les indications de formatage du texte.

Toujours le même exemple, une nouvelle section en MediaWiki :

= Nouvelle section Wiki =

et une en Setext :

Nouvelle section Setext
=======================

Mais pourquoi limiter ces langages de balisage léger à la seule génération de HTML ? Pourquoi ne pas utiliser la même syntaxe pour différentes cibles (appelées backends, targets ou writers selon les logiciels), de manière à obtenir aussi bien une page web en HTML, qu’un document en LaTeX pour l’impression, ou qu’une page de man pour un logiciel ? Ce sont les logiciels qui poursuivent ce but qui m’intéressent, ils constituent pour moi l’avenir de la bureautique informatique, et j’ai été amené à les comparer pour en choisir un dans lequel m’investir comme développeur.

Voici un tableau comparatif des meilleurs logiciels libres existants, avec comme information supplémentaire l’existence d’une cible texte brut, puisque je souhaitais me baser sur ce code pour programmer certaines de mes idées ASCII art.

Les logiciels complets MAJ

NomLangage de programmationPopularité du projeti18nCible texte brutLicence
Txt2tagsPythonmoyenne + RedNotebookOui + docOuiGNU GPLv2 ou suivante
DocutilsPythonforte + SphinxNonNonDomaine public
AsciiDocPythonforteNonDump de w3m ou de LynxGNU GPLv2 ou suivante
DeplateRubyfaibleNonOuiGNU GPLv2 ou suivante
PandocHaskellmoyenneNonOuiGNU GPLv2 ou suivante
Stx2anySed et m4faibleNonDump de w3mLicence copyleftée personnalisée
AFTPerlfaibleNonNonClarified Artistic License
LunamarkLuafaibleNonNonMIT
JeromeErlangfaibleNonNonMIT
DoxiaJavaforteNonNonApache License 2.0
XWiki RenderingJavafaibleNonOuiGNU LGPLv2.1

Exceptés Docutils et AFT (Almost Free Text), tous les logiciels semblaient au premier abord proposer une cible texte. Mais en fait c’est un peu un trompe l’œil, car deux d’entre eux, AsciiDoc et Stx2any, se contentent de dumper un navigateur web en mode texte (w3m ou Lynx) du résultat généré par leur cible HTML. Il n’y avait donc pas dans ces cas de base de code que je pouvais espérer améliorer.

J’ai mis dans le comparatif stx2any et AFT codés respectivement en m4 et en Perl, de manière à proposer un large éventail de langages de programmation, mais ces logiciels sont à la fois moins utilisés et dotés de moins de fonctionnalités que les autres. En étudiant les différents logiciels disponibles, je me suis rendu compte que, par chance pour moi, beaucoup étaient codés en Python (3 sur 11 au total, mais surtout 3 sur les 5 vraiment intéressants). Ce n’est d’ailleurs pas la première fois que je constate, en cherchant à sélectionner des logiciels libres, que ceux codés en python sont à la fois les plus nombreux et les meilleurs.

Les cinq logiciels restants sont vraiment excellents, et constituent tous un bon choix. Trois d’entre eux, Docutils, Deplate et Pandoc, ont un design évolué, avec une machine à états finis pour laquelle on peut écrire de nouveaux readers et writers de manière parfaitement propre. Cependant, malgré leurs grandes qualités, Deplate est un projet trop confidentiel (ainsi il n’est incompréhensiblement pas présent parmi les pourtant si nombreux paquets Debian), et je ne me sentais pas à la hauteur pour m’investir dans un projet comme Pandoc, totalement écrit en Haskell, qui est un langage de programmation complexe que j’aimerais beaucoup utiliser, mais où ma compétence est encore trop limitée.

Il fallait donc que j’approfondisse ma réflexion sur les logiciels en Python :

Choix en Python

NomCibles principalesCible texte brut
Txt2tagsHTML, Latex et syntaxes WikiOui
DocutilsHTML et LatexNon
AsciiDocHTML et DocBookDump
MarkdownHTMLNon
TextileHTMLNon

J’ai rajouté dans ce comparatif Markdown et Textile, puisqu’ils ont chacun une implémentation en Python, mais ne générant que du HTML, ils ne m’intéressaient pas vraiment. AsciiDoc et Txt2tags ont un peu la même architecture, avec un gros fichier principal faisant tout le travail, que l’on peut configurer, respectivement avec un fichier .conf et deux dictionnaires Python (un pour les Tags et l’autre pour les Rules), pour créer de nouvelles cibles. AsciiDoc et Txt2tags sont donc plus aisés à prendre en main et à modifier rapidement que Docutils, qui est une très belle et très bien architecturée machine à états objet, mais aussi plus difficile à appréhender.

De plus, comme je désapprouvais totalement la politique de licence domaine publique de Docutils, il ne me restait plus qu’à faire mon choix entre Txt2tags et AsciiDoc. C’est principalement l’orientation très DocBook (un format ne m’intéressant personnellement pas du tout) d’AsciiDoc, et d’autres détails, comme la localisation en de nombreuses langues de Txt2tags et sa plus grande simplicité, qui m’ont finalement fait choisir Txt2tags.

Ce choix est confirmé par une étude plus avancée des différentes syntaxes. Ainsi alors que la syntaxe reST de Docutils ne dispose que de :

*italique* et **gras**

Txt2tags est beaucoup plus riche :

//italique// **gras** __souligné__ et --barré--

Le codage visuel est bien meilleur, et le compréhension instantanée avec la syntaxe de Txt2tags, puisque les slashs donnent l’impression penchée de l’italique, les étoiles imitent la surcharge du gras, les underscores donnent l’impression de soulignement, et les moins apparaissent comme une barre. De plus, l’utilisation généralisée des caractères de balisage en doubles, permet de lever à peu de frais un maximum d’ambiguïtés syntaxiques.

Par exemple une phrase aussi simple que celle contenue dans le fichier d’exemple de Txt2tags :

We use double *, /, - and _ to represent **bold**, //italic//, --strike-- and __underline__.

et qui ne pose aucun problème :

est en fait déjà trop ambigüe en reST, puisque :

We use double *, /, - and _ to represent **bold**, *italic*, strike and underline.

donnera :

De manière générale, la syntaxe reST est souvent trop lourde. Par exemple dans le cas de l’insertion d’une image servant de lien :

.. image:: picture.png
:target: http://fgallaire.flext.net

que l’on peut comparer avec le beaucoup plus simple Txt2tags :

[[picture.png] http://fgallaire.flext.net]

On remarque bien sûr ici que la syntaxe reST offre sûrement plein d’autres options que la simple :target:, et qu’elle est donc plus puissante que celle de Txt2tags. Cependant, mon avis est que la pénalité de lourdeur est toujours présente, alors qu’elle n’est utile que dans peut-être 1% des cas.

Voici maintenant un comparatif des logiciels disponibles par syntaxe :

Classement par syntaxe

UsageTxt2tagsAsciiDocreStructuredTextMarkdown
BureautiqueTxt2tagsAsciiDocDocutils
Pandoc
Pandoc
Web serveurTxt2tags (Python)
PHP
AsciiDoc (Python)Docutils (Python)Perl
Python
Ruby
PHP
Erlang
Java
Web clientmarked
Showdown
markdown-js

Leur implémentation en Python permet à Txt2tags, reST (par Docutils) et AsciiDoc d’être utilisables à la fois comme logiciels de bureautique multiplateforme (Linux, Mac OS X, Windows et *BSD) et pour le web côté serveur. Depuis 2012, une implémentation de txt2tags en PHP est disponible, développée par Petko Yotov (le mainteneur et principal développeur de PmWiki) et sponsorisée par Eric Forgeot. En face, Markdown est représenté par une armada d’implémentations dans tous les langages utilisés sur le web côté serveur, et aussi en JavaScript côté client pour des prévisualisation efficace sans Ajax, mais seul Pandoc, qui n’est pas si facile à compiler sur toutes les plateformes, propose autre chose qu’un rendu en HTML.

Je vais bien sûr continuer à travailler sur le logiciel Txt2tags, mais une implémentation de la syntaxe Txt2tags en JavaScript pour un rendu live sur le net, ainsi que des readers Pandoc, car j’ai vraiment envie de programmer en Haskell, et Docutils, pour pouvoir bénéficier ensuite du sublime Sphinx, sont des projets qui me motivent de plus en plus.

Enfin, je suis toujours un peu nostalgique devant ce screenshot, parce que c’est en le voyant, avec en haut à gauche le fichier avec les balises, et en bas à droite celui avec le résultat texte brut, que j’ai pris conscience que Txt2tags faisait bien ce que j’espérais, et que comme en plus il était en Python, ce serait probablement le logiciel auquel j’allais contribuer !

Mise à jour du 27 mai 2013 : Ajout dans le tableau comparatif des logiciels de Lunamark en Lua et de Jerome en Erlang. Ajout dans le tableau de classement par syntaxe de txt2tags-php.

Mise à jour du 26 février 2014 : Ajout dans le tableau comparatif des logiciels de Doxia et XWiki Rendering en Java. Ajout dans le tableau de classement par syntaxe de marked, markdown-js, erlmarkdown et XWiki Rendering.

Txt2tags 2.6 est arrivé !

Friday, November 5th, 2010

Le voilà enfin, après plus de deux ans d’attente, txt2tags 2.6 est arrivé !

Txt2tags est un langage de markup, c’est-à-dire qu’il utilise une syntaxe non-obstrusive pour signifier les propriétés des éléments de texte, une syntaxe wiki en plus puissante. Mais à la différence des wiki qui ne génèrent que du HTML, txt2tags permet, à partir du même fichier source, de générer pas moins de 18 formats différents (appelés target) : HTML, XHTML, SGML, DocBook (NEW), LaTeX, Lout, Man page, Creole (NEW), Wikipedia / MediaWiki, Google Code Wiki, PmWiki (NEW), DokuWiki, MoinMoin, MagicPoint, PageMaker, AsciiDoc (NEW), ASCII Art (NEW) et Plain text.

J’ai commencé à m’investir dans txt2tags car je suis convaincu que le modèle de bureautique WYSIWYG actuel, promu par des usines à gaz mastodontiques, fussent-elles libres comme LibreOffice, est une véritable impasse. Par chance, les principaux logiciels intéressants dans ce domaine (txt2tags, docutils/ReST et AsciiDoc), sont écrits en Python, mon langage de programmation de prédilection.

Si j’ai choisi txt2tags c’est parce que c’était le code le plus simple à modifier pour faire les expérimentations qui m’intéressaient. Et puis Aurélio Jargas, le principal développeur, a ouvert son développement anciennement très solitaire/centralisé grâce au site Google Code. Il m’a donné les droits de commit SVN à la seconde où je l’ai contacté. Ce très bon feeling humain s’est poursuivi et a permis une collaboration technique, puisque si j’ai eu pas mal d’idées et que je les ai implémentées fonctionnelles et non buggées, Aurélio a fait un sacré travail derrière pour que l’intégration de mes modifications fassent moins “hack”.

Mon traditionnel et important point de juriste :-) : txt2tags est sous licence GNU GPLv2, qui est soumise à un Copyleft fort, ce qui garantit la liberté éternelle de mon travail. Bien qu’un relativement petit projet en terme de nombre de lignes de code, la communauté autour de txt2tags est grande et mondiale, et il est donc localisé dans plus d’une dizaine de langues (chaînes de caractères dans le code ET documentation) !

Beaucoup de nouvelles fonctionnalités dans cette version 2.6, dont ma nouvelle target ASCII Art sur laquelle je reviendrai plus en détail, mon set markItUp! pour une utilisation aisée sur le web, la possibilité d’inclure des tableaux de fichiers CSV externes, et un nom de domaine txt2tags.org, pour donner plus de visibilité au site web.

Je suis très heureux et très fier de pouvoir faire cette annonce, car cela fait pas loin de deux ans que je me suis engagé dans ce projet, et que cette release permet de rendre accessible au grand public ma première contribution significative aux logiciels libres !