il avait été évoqué une discussion autour de Markdown pour les sujets de la SpipNoz Brestoise.
Je ne sais pas si le sujet est maintenu, et si tous les protagonistes intéressés y seront, mais est-ce qu’on ne pourrait pas ouvrir une page wiki à ce sujet, pour recenser les options fonctionnelles, techniques etc. sur ce point pour le faire avancer un peu ?
il avait été évoqué une discussion autour de Markdown pour les sujets de la SpipNoz Brestoise.
Bonne idée !
Il y a plusieurs choix :
a) adopter Markdown et laisser tomber la syntaxe SPIP, hop
b) ajouter Markdown, en plus de la syntaxe SPIP, et permettre de choisir l'une ou l'autre pour la rédaction, soit pour l'ensemble du site, soit article par article, soit auteur par auteur
c) compléter la syntaxe SPIP avec la syntaxe Markdown, pour utiliser une syntaxe hydride, rétrocompatible
d) développer un plugin pour Markdown, qui y ajoute les raccourcis SPIP
Sans oublier qu'il n'y'a pas que Markdown, qui n'est ni l'unique solution, ni irréprochable.
Je propose de faire un point à la SPIPnoz — sous réserve d'avoir le temps de préparer — sur la saisie et ses interfaces, WYSIWYG, syntaxiques, etc.
Je ne pourrai pas être à la SPIPnoz mais suis super intéressé par vos dicussions. Je mets à Markdown dans un autre contexte (travail avec R et le format Rmd géré par RStudio, cf http://www.rstudio.com/ide/docs/authoring/using_markdown et http://rpubs.com/). Et j’ai découvert pandoc (http://johnmacfarlane.net/pandoc/) qui étend Markdown (comme de très nombreux autres, pandoc intégrant d’ailleurs d’autres travaux) avec quelques petits trucs bien intéressant comme la gestion des notes de bas de page ou des références bibliographiques ou la numérotation des titres, les liens intra documents… Je me dis que cela peut aussi nourir la réflexion.
Avant de s'attaquer aux petits détails de syntaxe, on aura à discuter de
plusieurs choses :
1. est-ce qu'on veut/doit essayer de s'inscrire dans l'"écologie" qui se
développe autour de Markdown
2. Quels seraient les avantages ?
3. Quel serait le prix à payer, inacceptable, ou acceptable selon les cas :
- perte de compatibilité
- perte de repères utilisateurs
- "fork" entre les textes au format SPIP et les textes au format markdown
- effort de programmation pour des convertisseurs "one shot" ou
"permanents"
- effort de documentation
- utilisation d'un format pivot neutre (de fait, ça ne pourrait être que
HTML)
4. Réflexion générale sur la pérennité des contenus
Que se passera-t-il si (quand) PHP, MySQL, disparaîtront. Comment rendre
pérenne le travail éditorial réalisé durant des dizaines d'années sur des
dizaines de milliers de sites SPIP. A court terme, les avantages d'un SPIP
"offline" basé sur des contenus sous forme de fichiers statiques (+
réflexion sur formats et convertisseurs).
5. Gestion des "liens" dans un document texte (raccourcis <img> <doc> et
<modèles>) : comment faire sain, pérenne, portable (réflexion démarrée
mollement avec le plugin "<ressource>").
Avant de s'attaquer aux petits détails de syntaxe, on aura à discuter de
plusieurs choses :
1. est-ce qu'on veut/doit essayer de s'inscrire dans l'"écologie" qui se
développe autour de Markdown
Ce qui pose d'ailleurs la question des multiples versions/extensions de
Markdown.
Où/comment mutualiser, car la "version de base" de Markdown ne couvre pas
tous les besoins et usages de la syntaxe Spip existante.
5. Gestion des "liens" dans un document texte (raccourcis <img> <doc> et
<modèles>) : comment faire sain, pérenne, portable (réflexion démarrée
mollement avec le plugin "<ressource>").
Ce qui renvoie aussi aux débats sur comment cela est traité dans d'autres
projets (j'ai en tête toutes les discussions autour de pandoc sur comment
indiquer le titre d'un tableau, d'une figure etc. mais je suppose que cela
est aussi discuté dans d'autres projets autour de md).
PS : C'est probablement trop tôt pour l'inclure dans la réflexion mais il
y a aussi des approches pour intégrer différents champs dans un même
fichier markdown, par exemple sous pandoc la possibilité de mettre un yaml
introductif avec des méta-données comme titre, auteurs, résumés,
mots-clés... Ce type d'approches permettrait de faciliter des publications
par import d'un fichier texte ou envoie par email etc.
PS : C'est probablement trop tôt pour l'inclure dans la réflexion mais
il y a aussi des approches pour intégrer différents champs dans un même
fichier markdown, par exemple sous pandoc la possibilité de mettre un
yaml introductif avec des méta-données comme titre, auteurs, résumés,
mots-clés... Ce type d'approches permettrait de faciliter des
publications par import d'un fichier texte ou envoie par email etc.
Ce serait pas mal aussi d'avoir quelque chose qui permet de gérer les
événements/dates directement dans la saisie en mode texte. Je sais pas
si Pandoc ou Markdown ont normalisé des choses de ce côté là.
Sinon, je me disais qu'un bout de JS (ou un retour de formulaire en php)
qui voyant une date, proposerait d'en faire un événement pourrait
faciliter la saisie. Il me semble que Apple ou Google ont des choses
comme ça dans certains de leurs éditeurs de mail (ou intégrer une carte
quand y'a une adresse...).