Le tan­go des édi­teurs mark­down

Écrire en mark­down pré­sente de nom­breux avan­tages, notam­ment en termes d’interopérabilité et de conver­sion de docu­ments. Encore faut-il avoir à dis­po­si­tion un envi­ron­ne­ment de tra­vail adé­quat. De nom­breux inven­taires recensent des édi­teurs en ligne fort agréables, mais qui ne se prêtent pas for­cé­ment à tous types de tra­vaux. Voi­ci une expli­ca­tion de mes choix.

Le contexte

Tout à com­men­cé lorsque, pour les besoins édi­to­riaux de la col­lec­tion Fra­ma­book, les limites d’une unique ligne édi­to­riale se sont fait sen­tir. En gros, il s’agissait de tra­vailler les docu­ments en LaTeX, quitte à les conver­tir depuis les sources de l’auteur, pour les publier en PDF puis assu­rer leurs trans­for­ma­tions ulté­rieures en HTML et e-pub. Pour cer­tains ouvrages, notam­ment des manuels très spé­ci­fiques, cette ligne édi­to­riale n’a pas chan­gé, notam­ment parce que la publi­ca­tion en e-pub n’est pas for­cé­ment inté­res­sante. Pour d’autres ouvrages notam­ment des romans et des essais, la ques­tion s’est posée en ces termes dans la com­mu­nau­té Fra­ma­book : « com­ment évi­ter de devoir scin­der le pro­ces­sus de publi­ca­tion à la fin de la phase de relec­ture et devoir trans­for­mer des textes déjà for­ma­tés, avec tous les risques d’erreur que cela com­porte ? »

La pre­mière par­tie de la solu­tion était assez simple : trou­ver un for­mat qui soit facile d’utilisation, com­pré­hen­sible par tout le monde1, et sur­tout d’assez bas niveau pour pou­voir être trans­for­mé effi­ca­ce­ment dans d’autres for­mats. Mark­down pré­sente l’avantage d’être simple et, bien que sa syn­taxe offi­cielle soit très basique, il existe la pos­si­bi­li­té de lais­ser à des logi­ciels la pos­si­bi­li­té d’adapter cette syn­taxe au for­mat de sor­tie vou­lu. C’est ain­si par exemple que Pan­doc, un conver­tis­seur très puis­sant, peut venir s’interposer entre la source et le for­mat de sor­tie. Le texte de M. Domi­ni­ci « Un aper­çu de Pan­doc » pour­ra vous don­ner une idée assez pré­cise des capa­ci­tés de Pan­doc, en par­ti­cu­lier lorsqu’on couple la conver­sion avec des modèles préa­la­ble­ment dis­po­sés.

Les choix

Or, donc, pour tra­vailler de longs textes en mark­down, la ques­tion n’est pas tant de trou­ver un bon édi­teur mark­down que de se concoc­ter un envi­ron­ne­ment de tra­vail adap­té. C’est à dire qu’il faut pou­voir à la fois

  • édi­ter du texte avec un édi­teur dis­po­sant à mini­ma de la colo­ra­tion syn­taxique adap­tée au mark­down,
  • sto­cker ses fichiers et pou­voir les pas­ser à la mou­li­nette Pan­doc avec un ter­mi­nal,
  • être en mesure de trans­mettre ses fichiers en vue d’une édi­tion col­la­bo­ra­tive,
  • et faire le tout avec des logi­ciels libres.

Il existe une plé­thore de soit-disant « édi­teurs mark­down », cer­tains sont des édi­teurs de texte connus qui intègrent le for­mat mark­down dans leurs fonc­tion­na­li­tés, d’autres sont des édi­teurs en ligne plus ou moins effi­caces. Cet article sur Mashable recense pas moins de 78 édi­teurs mark­down. Beau­coup de ces édi­teurs ne sont pas libres bien qu’étant par­fois tout à fait effi­caces et agréables. Tous n’offrent pas d’interface wysiwyg, c’est à dire la pos­si­bi­li­té d’afficher « en live » la sor­tie HTML du docu­ment mark­down. C’est le cas par exemple du très bel édi­teur Sublime Text, mal­heu­reu­se­ment non libre.

Beau­coup de solu­tions sont en réa­li­té des édi­teurs en ligne. Beau­coup offrent des inter­faces avec des solu­tions cloud, c’est à dire la pos­si­bi­li­té d’éditer des docu­ments sto­ckés sur des espaces de type Drop­box. C’est le cas par exemple de Dillin­ger (sous licence as is), qui trans­forme votre navi­ga­teur en édi­teur mark­down soit pour enregistrer/éditer des fichiers locaux soit pour les sto­cker dans le cloud. Dans le même genre, Mark­down Din­gus est le conver­tis­seur « offi­ciel » de John Gru­ber, le créa­teur de mark­down.

Ce type de solu­tion est en réa­li­té adap­té à l’édition de docu­ments courts, sou­vent des­ti­nés à être affi­chés sur le web. C’est pour les mêmes rai­sons pra­tiques, que des CMS comme Word­Press pro­posent désor­mais le mark­down pour édi­ter des articles. Une autre appli­ca­tion de cela est illus­trée par Strapdown.js qui per­met d’insérer direc­te­ment dans une page HTML des élé­ments en mark­down, le tout affi­ché avec un style Boots­trap, très pra­tique pour édi­ter très rapi­de­ment des pages web élé­gantes.

Mais tout cela n’est guère adap­té à l’édition…

Qu’est-ce qu’un bon édi­teur mark­down ?

Comme je tra­vaille sous GNU/Linux, je répon­drai à cette ques­tion en adop­tant une pos­ture « Unixienne » : un bon logi­ciel est un logi­ciel qui fait juste ce que vous lui deman­dez et le fait bien. C’est-à-dire pas un mou­lin bour­ré d’options dont vous n’avez pas l’usage, ni un édi­teur qui réin­vente la pluie sous pré­texte d’être moderne et qui marche moins bien que l’éditeur avec lequel vous tra­vaillez depuis des années. Donc il n’y a pas de mau­vais édi­teur dans le sens où si vous y trou­vez votre compte, tout va bien. Par contre je ne par­le­rai pas de ceux qui ne sont pas libres /open source, et je vais me concen­trer sur mes usages per­son­nels.

Git­book : oui, mais non

[edit du 01 juin 2017 : les argu­ments ci-des­sous laissent à pen­ser que Git­book n’est uti­li­sable que sous Github, mais il s’agit de l’interface. Git­book, le moteur, lui, est uti­li­sable avec n’importe quel ser­vice basé sur Git (com­me­Git­lab), mais on ne peut alors uti­li­ser l’interface pro­po­sée par Git­book, le ser­vice.]

Un bel exemple de bou­zin, c’est le pro­jet Git­book (sous licence Apache). Mais je vais être gen­til : il est beau, accueillant, et per­met d’utiliser des dépôts Git (sur Github) sans se perdre dans les lignes de com­mandes. Son défaut ? se concen­trer uni­que­ment sur l’édition de livres (c’est nor­mal, vu son nom) mais en vou­lant inté­grer tout une ligne édi­to­riale d’un seul tenant, de l’édition du docu­ment mark­down à sa publi­ca­tion en PDF voir en papier.

Dédié à la rédac­tion col­la­bo­ra­tive, Git­book per­met d’éditer un livre à plu­sieurs mains en tra­vaillant au for­mat mark­down. L’interface web d’édition, dans la ver­sion gra­tuite, est fort bien conçue : outre l’aperçu direct de la sor­tie HTML, ses outils per­mettent d’exporter le docu­ment en HTML ou PDF, et il est pos­sible d’uploader direc­te­ment des fichiers (au for­mat mark­down, ou bien des images, etc.). Un fichier Summary.md per­met de fabri­quer le som­maire de l’ouvrage. Par ailleurs, il est pos­sible d’interfacer direc­te­ment Git­book avec un compte Github, ce qui pré­sente deux avan­tages :

  1. la syn­chro­ni­sa­tion entre les fichiers avec le dépôt Github fonc­tionne dans les deux sens, si bien qu’il est pos­sible de pous­ser ses fichiers rédi­gés loca­le­ment pour mettre à jour le livre sous Git­book, en inver­se­ment.
  2. Il n’est pas pos­sible, sauf par copier/coller de récu­pé­rer le source mark­down depuis Git­book, donc pou­voir le faire depuis le dépôts Github se révèle plu­tôt pra­tique.

Le prin­ci­pal défaut de Git­book, je l’ai dit, c’est de pen­ser l’ensemble comme une solu­tion édi­to­riale. Or ce n’est pas le cas. Pre­miè­re­ment parce que trans­for­mer du mark­down vers du HTML puis vers du PDF, revient ni plus ni moins à vou­loir impri­mer une page web. Il est certes pos­sible de confi­gu­rer les styles de son ouvrage, mais la typo­gra­phie ne sera jamais au ren­dez-vous. Sauf à se conten­ter de for­mat HTML ou E-Pub, il n’est pas sérieux de pré­tendre rem­pla­cer un logi­ciel fait pour l’édition papier comme LaTeX. Mais ce n’est pas le plus impor­tant des griefs : il n’est pas pos­sible de gérer une biblio­gra­phie digne de ce nom et toutes les sub­ti­li­tés édi­to­riales passent à la trappe comme par exemple la ges­tion des notes de bas de page, notes de fin, ou de fin de cha­pitre, les index, les tables des matières et les som­maires, les éti­quettes, etc. Tout se passe comme si tous ces élé­ments devaient être construits « à la main », direc­te­ment en HTML, ce qui est loin de faci­li­ter la rédac­tion.

C’est la gre­nouille qui se prend pour le boeuf : les outils inté­grés qui pré­tendent à la fois s’affranchir des for­mats et pro­duire des sor­ties adap­tées à tous les sup­ports, n’existent pas.

Gitbook Editor
Git­book Edi­tor

Pour­tant le pro­jet Git­book a pro­duit un édi­teur mark­down très inté­res­sant qui allie l’édition wysiwyg et la ges­tion des fichiers com­po­sant l’ouvrage. Cet édi­teur en ligne existe aus­si en ver­sion locale sous le nom Git­book Edi­tor. Très simple à l’installation (et tou­jours sous licence Apache), il per­met de syn­chro­ni­ser vos fichiers comme expli­qué pré­cé­dem­ment sans tou­te­fois dépendre d’une connexion Inter­net.

Néan­moins, s’il ne s’agit plus que d’utiliser un édi­teur mark­down et syn­chro­ni­ser des fichiers, hé bien, il suf­fit dans ce cas soit d’enregistrer direc­te­ment ses fichiers dans un dos­sier syn­chro­ni­sé sur un compte cloud soit d’utiliser Git sur un compte Git­lab (ou Github). Dans les deux cas, il pos­sible de rédi­ger de manière col­la­bo­ra­tive sans avoir besoin de dis­po­ser d’une inter­face web. Le prin­ci­pal avan­tage de Git­book réside dans son appa­rente sim­pli­ci­té d’utilisation, mais au prix d’un résul­tat plu­tôt moyen.

En local, un édi­teur mark­down wysiwyg qui a lar­ge­ment fait ses preuves, c’est Re-Text. Sa sim­pli­ci­té d’utilisation est confon­dante et l’aperçu HTML est de très bonne qua­li­té. Notons qu’il per­met l’export en HTML, PDF mais aus­si ODT, ce qui est assez appré­ciable d’autant plus que ces exports sont très propres.

Pour­tant, ReText n’est pas encore à la hau­teur de mes attentes.

Retext
Retext

Édi­teurs de la Vieille école

Oui, je vous vois venir de loin : n’ayant pas trou­vé mon bon­heur dans les nou­veau­tés, je cache mon inadap­ta­tion chro­nique de vieux schnock der­rière la nos­tal­gie du « c’était mieux avant »…

Détrom­pez-vous, ce n’est pas le cas. Je rap­pelle juste un point : n’importe quel édi­teur peut faire l’affaire, pour­vu que la colo­ra­tion syn­taxique puisse inté­grer le mark­down et qu’il soit pos­sible de faire ce qu’on veut avec les fichiers sources.

L’important, c’est de trou­ver un édi­teur le plus agréable pos­sible et dont l’interface per­mette faci­le­ment ces mani­pu­la­tions. Voi­ci donc, de manière affi­née, le cahier des charges :

  • colo­ra­tion syn­taxique mark­down,
  • aper­çu HTML (en wysiwyg) non obli­ga­toire mais appré­ciée,
  • un ter­mi­nal inté­gré (pour com­pi­ler avec Pan­doc et même LaTeX),
  • un navi­ga­teur de fichiers,
  • une inter­face agréable (si pos­sible confi­gu­rable à sou­hait).

Pour le reste, Pan­doc nous per­met­tra aus­si de gérer toutes sortes de petits à-côtés, de la biblio­gra­phie à l’utilisation de modèles, et une foule d’options adap­tées à l’édition. Cela implique for­cé­ment d’utiliser une saveur de mark­down à la « sauce » Pan­doc. D’où l’importance d’avoir un édi­teur de texte dont la colo­ra­tion syn­taxique sera capable de com­prendre plu­sieurs lan­gages autres que le mark­down, sus­cep­tible d’être inté­grés direc­te­ment dans le docu­ment source : le HTML, bien sûr, mais aus­si du LaTeX, par exemple. Pour rap­pel, repor­tez-vous ici pour com­prendre tout ce que Pan­doc peut faire.

Gedit et Gea­ny

Tout cela pour en arri­ver là… Gedit et Gea­ny sont des édi­teurs de texte figu­rant par­mi les plus connus du Libre. À mon sens, c’est jus­te­ment à cause de cela que leurs fonc­tion­na­li­tés ont été pen­sées au plus près des évo­lu­tions des usages, et l’édition de texte en mark­down figure par­mi celles-çi.

Au moins dans leurs ver­sions récentes, ces deux édi­teurs pos­sèdent des fonc­tion­na­li­tés adap­tées au mark­down, à com­men­cer par un pan­neau d’aperçu du ren­du HTML. Leurs autres avan­tages est de per­mettre de navi­guer dans l’arborescence, d’ouvrir plu­sieurs fichiers en même temps et d’avoir une inter­face de ter­mi­nal inté­grée, ne serait-ce que pour com­pi­ler.

Leurs dif­fé­rences ? Alors que Gea­ny s’installe avec toute une bat­te­rie de fonc­tion­na­li­tés par­fois assez sophis­ti­quées, il faut ins­tal­ler ses gref­fons à Gedit. Là où Gea­ny pro­pose une inter­face assez com­plète per­met­tant de confi­gu­rer les pré­fé­rences de l’éditeur, Gedit mise sur la sim­pli­ci­té. Dans les deux cas, pour ce qui concerne l’édition en mark­down, la confi­gu­ra­tion reste la même à peu de choses près.

Dans les cap­tures d’écran sui­vantes, j’ai sim­ple­ment pla­cé la barre d’aperçu HTML en bas (à coté du ter­mi­nal inté­gré) dans Gedit, alors qu’elle figure dans le pan­neau de gauche sous Gea­ny.

Avec ces deux logi­ciels (sous GTK) il est alors pos­sible de tra­vailler des docu­ments en mark­down de les conver­tir avec Pan­doc, les com­pi­ler avec LaTeX, édi­ter des modèles LaTeX et HTML, édi­ter les sor­ties LaTeX et HTML si besoin, pous­ser les fichiers sur un dépôt Git, tout cela sans jamais sor­tir de l’interface. Et encore, même pour voir le ren­du PDF, il est pos­sible d’ajouter un pan­neau qui fera tour­ner un lec­teur PDF comme Evince.

Il y a deux petites choses qui me font pré­fé­rer Gedit pour l’écriture :

  • je trouve que la colo­ra­tion syn­taxique du mark­down sous Gedit est plus évo­luée que sous Gea­ny, à moins d’avoir quelques minutes pour la confi­gu­rer selon ses sou­haits.
  • sous Gedit, j’ai trou­vé un thème qui m’est vrai­ment agréable pour les yeux. il se nomme Build et il est dis­po­nible sur la liste des thème pour Gedit.

Ces deux élé­ments peuvent être retrou­vés sans nul doute sous Gea­ny, mais en pas­sant un peu plus de temps dans la confi­gu­ra­tion.

Fina­le­ment, on est vrai­ment pas loin d’Emacs, sauf que je n’ai jamais résis­té à plus de 5 minutes d’apprentissage… mais je suis per­sua­dé que d’autres que moi y trou­ve­ront lar­ge­ment leur compte.

D’autres édi­teurs de texte pour­ront de même être tes­tés, il suf­fit pour en obte­nir une liste assez exhaus­tive de se pen­cher sur la com­pa­rai­son sur cette page Wiki­pé­dia.

Gedit
Gedit
Geany
Gea­ny

Conclu­sion

Autant il est facile d’apprendre la syn­taxe mark­down, autant il est impor­tant de bien choi­sir les outils qui per­met­tront de trai­ter les fichiers sous ce for­mat, en fonc­tion du but recher­ché. S’il ne s’agit que d’écrire un billet de blog, n’importe quel édi­teur de texte pour­vu de la colo­ra­tion syn­taxique (et encore) fera l’affaire. Choi­sis­sez-le sous licence libre si pos­sible car tout ce que pro­posent de plus les édi­teurs non libres sont des inter­faces (par­fois) très agréables, mais c’est tout.

Pour l’édition de docu­ments longs, avec des exi­gences de mise en page, de typo­gra­phie et d’utilisation de don­nées (comme de la biblio­gra­phie), le mark­down est d’abord à conce­voir comme un outil de sai­sie rapide et propre à être conver­ti en plu­sieurs for­mats. Dans ce cas, il est impor­tant d’utiliser des édi­teurs de textes qui pro­posent des outils de trai­te­ment des opé­ra­tions néces­saires à la conver­sion. L’expérience apprend qu’il est presque tou­jours néces­saire de retou­cher les fichiers ain­si conver­tis en vue d’une publi­ca­tion, et ces retouches doivent être fai­sables avec le même édi­teur, de manière à ne pas avoir à chan­ger d’interface pour chaque opé­ra­tion.

Quitte à res­ter simple dans le for­mat de départ (mark­down), autant res­ter simple dans le choix de l’éditeur. L’utilisation de la ligne de com­mande n’est pas une obli­ga­tion, mais c’est quand même très pra­tique.

Pour ce qui concerne l’édition col­la­bo­ra­tive, la solu­tion de syn­chro­ni­ser sur un dépôt Git me semble la plus recom­man­dée. On pour­ra éven­tuel­le­ment uti­li­ser Git­book mais il ne fonc­tionne que sous Github (dont on sait la poli­tique pas fran­che­ment libre). Avoir un dépôt cloud basé par exemple sur Own­cloud, peut aus­si être une bonne alter­na­tive. Il suf­fit alors de syn­chro­ni­ser le dos­sier dans lequel on tra­vaille. On peut aus­si signa­ler que Own­cloud dis­pose en ligne d’un plu­gin qui per­met d’éditer des fichiers mark­down, cepen­dant peu adap­té à de gros docu­ments.


  1. Cer­tains pensent tou­jours que LaTeX est réser­vé à une élite, ce qui est vrai, mais tout le monde peut en faire par­tie !

Christophe

Fram(hack)tiviste, je fais du vélo et je mange des châtaignes.