RastaPopoulos a écrit le 20/05/2019 à 12:47 :
Si on passe à Markdown, il faut dans tous les cas continuer de
post-process le texte avec une librairie (à nous, ou maintenue ailleurs
dans la communauté PHP) de correction typographique suivant les langues.
En lib qui marche bien, il y a :
https://github.com/jolicode/JoliTypo
(avec explications de l'auteur : https://jolicode.com/blog/la-micro-typographie-appliquee-sur-le-web)
--
RealET
Pouet,
Le lun. 20 mai 2019 à 12:47, RastaPopoulos <rastapopoulos@spip.org> a écrit :
On est quand même aussi dans le monde anglo-saxon avant tout.
Je ne dis pas que c’est mal, je dis simplement que si on migre ça serait
bien de ne pas perdre de la typo qui fonctionne aujourd’hui sur SPIP au
profit d’un standard orienté technique.Les corrections typographiques n’ont strictement rien à voir avec la
syntaxe légère. Ce sont des corrections automatiques, sans rapport avec
un langage spécifique qu’on insère dans le texte.
Ouep toutafé, j’ai mélangé les deux.
Je suis confus =>[]
SPIP fait la deux, corrections typos + une syntaxe précise. Markdown
c’est juste une syntaxe.
Oui donc faudra compléter de la même façon.
Je ne saisis pas trop pourquoi il faudrait comparer par « type de doc ».
Je parle bien d’une comparaison exhaustive des langages raccourcis par
raccourcis.
Non ce que je veux dire c’est qu’on doit avoir le même rendu pour tout type de doc.
Mais je pense que c’est aussi un problème plus de typo que de syntaxe.
Il y a une liste de raccourcis précis qui composent chacun des deux
langages de syntaxe légère, il faut les comparer un par un, lesquels
sont équivalents, lesquels ne sont que dans l’un ou que dans l’autre, où
sont les manques.
Oui ça serait bien de faire ça et d’avoir aussi un texte de référence qui vérifie bien le rendu.
Et hop un chantier de plus.
++
Eric
Bon, je prendrai pas la peine de répondre à tout ça, je dirai juste : essayez le plugin MD qui y réponds
(ou lisez au moins le Readme.md)
https://github.com/Cerdic/markdown
Notez bien le TODO d’il y a 5 ans qui reste valide:
* proposer un chemin de migration des contenus
* travailler sur la question de l’éditeur/barre typo (à l’époque je pensais à reconfigurer Porte Plume, mais je pense maintenant qu’il faut carrément switcher vers un éditeur MD)
--
Cédric
Le 20 mai 2019 à 14:19 +0200, Eric Lupinacci <eric@smellup.net>, a écrit :
Pouet,
> Le lun. 20 mai 2019 à 12:47, RastaPopoulos <rastapopoulos@spip.org> a écrit :
> > > On est quand même aussi dans le monde anglo-saxon avant tout.
> > > Je ne dis pas que c'est mal, je dis simplement que si on migre ça serait
> > > bien de ne pas perdre de la typo qui fonctionne aujourd'hui sur SPIP au
> > > profit d'un standard orienté technique.
> >
> > Les corrections typographiques n'ont strictement rien à voir avec la
> > syntaxe légère. Ce sont des corrections automatiques, sans rapport avec
> > un langage spécifique qu'on insère dans le texte.
> >
>
> Ouep toutafé, j'ai mélangé les deux.
> Je suis confus =>[]
>
> > SPIP fait la deux, corrections typos + une syntaxe précise. Markdown
> > c'est juste une syntaxe.
> >
>
> Oui donc faudra compléter de la même façon.
>
> > Je ne saisis pas trop pourquoi il faudrait comparer par "type de doc".
> > Je parle bien d'une comparaison exhaustive des langages raccourcis par
> > raccourcis.
> >
>
> Non ce que je veux dire c'est qu'on doit avoir le même rendu pour tout type de doc.
> Mais je pense que c'est aussi un problème plus de typo que de syntaxe.
>
> > Il y a une liste de raccourcis précis qui composent chacun des deux
> > langages de syntaxe légère, il faut les comparer un par un, lesquels
> > sont équivalents, lesquels ne sont que dans l'un ou que dans l'autre, où
> > sont les manques.
> >
>
> Oui ça serait bien de faire ça et d'avoir aussi un texte de référence qui vérifie bien le rendu.
> Et hop un chantier de plus.
>
> ++
> Eric
>
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
Le 20/05/2019 à 15:05, Cerdic a écrit :
Bon, je prendrai pas la peine de répondre à tout ça, je dirai juste :
essayez le plugin MD qui y réponds
(ou lisez au moins le Readme.md)
Voui voui, c'est connu et testé un peu. 
* travailler sur la question de l’éditeur/barre typo (à l’époque je
pensais à reconfigurer Porte Plume, mais je pense maintenant qu’il faut
carrément switcher vers un éditeur MD)
On nous a demandé ça ya pas très longtemps, et c'est ce qu'on a en tête
aussi.
Il existe même des éditeurs WYSIWYG avec vrai format pivot abstrait au
milieu (comme Prosemirror), et non pas juste des éditeurs de code stylé
(comme CodeMirror utilisé par SimpleMde).
Et c'est là l'avantage principal de passer totalement à MD : pouvoir
utiliser tout ce qui est déjà implémenté partout, et ne passer du temps
qu'à peaufiner les trucs spécifiques à SPIP.
On a notamment noté qu'il y aura de toute façon des choses à ajouter aux
implémentations :
- si c'est CodeMirror il faudra faire un format "MarkdownSPIP" qui
inclut la reconnaissance markdown existante mais en lui ajoutant le
parsing des modèles et des liens
- si c'est ProseMirror il faudra de même ajouter la prise en compte des
modèles et liens, dans les deux sens (parsing depuis la syntaxe vers le
format pivot JSON, et inversement pivot vers texte en syntaxe à
enregistrer en base)
Nous on est chaud patate pour tout ça 
--
RastaPopoulos
Yep,
Le lun. 20 mai 2019 à 15:05, Cerdic <cedric@yterium.com> a écrit :
Bon, je prendrai pas la peine de répondre à tout ça, je dirai juste :
essayez le plugin MD qui y réponds
(ou lisez au moins le Readme.md)
Bon essayé sur mon readme de la refonte de contrib.
Ca marche nickel et on voit bien le traitement des typos comme le ":" ou le
";".
Que penses-tu par contre du problème des tableaux ?
Si on passait à MD on ne garderait pas la syntaxe spip comme dans ton
plugin avec la balise <spip> non ?
++
Eric
Salut,
Je me permets de remonter quelques infos glanée ça et là
Le plugin de Cerdic intègre la lib parsedown
https://github.com/Cerdic/markdown/blob/master/README.md
# A propos des syntaxes et des libs php:
## PHP Parsedown (https://github.com/erusev/parsedown)
Parsedown c'est la lib php integrée au plugin de spip qui permet de
convertir la 'syntaxe de base' https://parsedown.org/
Parsedown ne reconnait que la syntaxe simple de markdown
https://www.markdownguide.org/basic-syntax
## PHP Parsedown-extra (https://github.com/erusev/parsedown-extra)
Parsedown-extra reconnait La syntaxe étendue de markdown
https://www.markdownguide.org/extended-syntax/
Il y a possibilité d'enrichir le plugin avec la librairie parsedown-extra
qui permet d'utiliser une syntaxe plus évoluée:
* gestion des tableaux
* blocks de code et colorisation
* Notes de pied de page
* Ancres sur titre personnalisées
* Liste de tâches
* Mots barrés (strike)
# MarkdownLint
Markdownlint est une lib js qui permet de valider le syntaxe markdown en
temp réel.
voir ici: https://dlaa.me/markdownlint/
Perso je l'utilise sur vscode est c'est génial pour produire un code
markdown parfait
# Un wysiwym
Un des nombreux wysiwyg existant que j'avais trouvé interessant
https://simplemde.com/
Voilà, cordialement.
Le lun. 20 mai 2019 à 15:31, Eric Lupinacci <eric@smellup.net> a écrit :
Yep,
Le lun. 20 mai 2019 à 15:05, Cerdic <cedric@yterium.com> a écrit :
Bon, je prendrai pas la peine de répondre à tout ça, je dirai juste :
essayez le plugin MD qui y réponds
(ou lisez au moins le Readme.md)Bon essayé sur mon readme de la refonte de contrib.
Ca marche nickel et on voit bien le traitement des typos comme le ":" ou
le ";".Que penses-tu par contre du problème des tableaux ?
Si on passait à MD on ne garderait pas la syntaxe spip comme dans ton
plugin avec la balise <spip> non ?++
Eric----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
Bref Donc pour revenir a la spec Markdown @+++
Hello,
Le mar. 21 mai 2019 à 07:29, GraphX <arnaud.berard@mister-graphx.com> a écrit :
Ca confirme rien du tout et j’ai l’impression que tu dit sans savoir ou avoir même essayé (comme git ou pakagist/composer, …) un peut ronchon quand c’est pas du made in spip quoi ^^ Comme si des millions de devs ne pouvaient pas arriver à la cheville du niveau de reflexion d’une dizaine de spipeur-se francophones, autour d’un framapad et quelques echanges mails…
.
Oui hier j’ai dit quelques conneries, je le reconnais sur la typo et la syntaxe MD.
Ca ne vaut pas je pense le procès d’intention que tu me fais sur Git, packagist, composer ni le dédain sur les spipeurs francophones qui ne le méritent pas.
J’espère ne pas être celui qui bloque le développement de SPIP depuis 8 ou 10 ans, ça serait bien prétentieux…
Peut-être devrais-tu t’appliquer ce que tu me reproches: relis ce que j’écris, j’ai écrit et toutes les propositions que j’ai faites depuis des années, peut-être alors tu auras une vision plus exacte…
Après si on en revient à MD, l’expérience récente m’a un peu déçu avec les tableaux, les guillemets et certaines listes (je me rappelle plus exactement le cas).
Mais je te rassure c’est la même chose avec SPIP.
Je pense que je suis 20 à 30% plus efficace pour rédiger une documentation correctement typographiée et présentée avec Word ou Google Docs qu’avec SPIP ou MD.
Et encore j’utilise les traitements de texte depuis bien 30 ans et en 1995 j’ai utilisé un logiciel sur SUN à Alcatel qui s’appelait Alice avec lequel tu ne pouvais pas faire un doc pourri; jamais je n’ai retrouvé un logiciel de cette efficacité.
Bref, je pense que je suis d’une génération qui préfère une doc papier bien présentée avec un sommaire qui explique la logique de ce qu’on va lire plutôt qu’une longue page MD ou SPIP. On ne se refait pas. Et dans le genre, WYSIWYG c’est surement le mal absolu mais c’est beaucoup plus inclusif que la syntaxe SPIP ou MD. Et si MD permet de faire que le WYSIWYG passe du coté clair de la force c’est une très bonne raison pour y passer (sur CodIMD l’éditeur avec la syntaxe à gauche et le rendu à droite est très efficace et rassurant, mais il faut une page assez large pour ça… :p).
Pour les autres calomnies ;-), Git et Composer.
Je n’ai rien contre, bien au contraire parce qu’il semble que ce soit un passage obligé pour que certains s’intéressent ou se ré-intéressent à SPIP.
Mais il ne faut pas que cela exclut d’autres contributeurs avec des profils moins « dev ».
Pour moi, qui suit un spipeur occasionnellement assidu mon but est de créer de la fonctionnalité et de ne pas perdre de temps sur les outils.
Ce type de changement doit être accompagné c’est tout.
Donc depuis quelques jours j’ai réactivé mon github, j’utilise Git/Github suivant l’ordi.
Je reste sur ma position initiale : Git fait tout et même le reste et c’est quand même une usine à gaz alors qu’on en utilise qu’une infime partie la plupart du temps.
Mais si on détoure bien son environnement on arrive à reproduire le checkout/commit/update de SVN qui suffit dans 95% des cas et des utilisateurs.
Je suis très fan par contre de Github et de son desktop qui arrive bien à faire émerger l’essentiel de git assez simplement.
Pour SPIP et son écosystème de plugins, le git SPIP, Gitea, etc, je suis plus dubitatif, je trouve Github plus facile d’accès mais c’est peut-être un point de vue subjectif.
Je peux dire qu’aujourd’hui je suis aussi presque aussi efficace en Git qu’en SVN (j’ai pas refait mon petit script svn de mise à jour de mes sites de dev) mais cela ne m’apporte rien de plus pour l’instant.
Composer c’est plus compliqué pour moi.
Déjà je pige pas trop le système dans son ensemble, et j’ai surtout du mal à entrevoir le lien entre le dev et la production.
Ma seule alerte concerne le référentiel des plugins qui tourne autour des XML et de smart-paquets.
Je dis juste attention, il faut préserver notre capacité à alimenter Plugins SPIP/Contrib surtout qu’on est en train de le refondre pour le rendre plus accessible et performant.
Voilà.
Quand je relis ce mail ça me déprime de devoir me justifier sur tout ça.
Je me demande si il n’est pas là, le vrai problème de SPIP.
++
Eric (qui fatigue et déprime un peu).
Le 21/05/2019 à 10:00, Eric Lupinacci a écrit :
Et dans le genre, WYSIWYG c'est surement le mal absolu mais c'est
beaucoup plus inclusif que la syntaxe SPIP ou MD.
Ce point est en bonne partie faux.
Romy et d'autres ont bien montré qu'en fait le WYSIWYG avec plein de
boutons était plus compliqué pour plein de gens pour réellement rédiger
au quotidien et encore pire pour rédiger pour le web/le multi-support.
C'est même extrêmement pas accessible pour les gens avec des handicaps.
C'est surtout rassurant pour les gens qui ont appris à écrire avec Word,
mais donc c'est juste une question d'habitude, et non pas de qualité
intrinsèque de l'ergonomie (tout comme si t'as appris l'ordi sur Win,
t'es perdu quand tu passes à Ubuntu : ou l'inverse).
Bref, je pense que je suis d'une génération qui préfère une doc papier bien présentée avec un sommaire qui explique la logique de ce qu'on va lire plutôt qu'une longue page MD ou SPIP
Tu compares la lecture, avec l'écriture, donc euuuh…
Personne ne "lit" en SPIP ou MD…
Les syntaxes légères servent à écrire sans avoir besoin d'enlever les
mains du clavier pour donner le sens des mots (bold etc), grace
justement à des caractères qu'on ajoute au fil du texte, sans devoir
cliquer sur 12 boutons. Après on génère exactement la même chose : des
docs numériques ou papiers avec un sommaire "qui explique la logique de
ce qu'on va lire", ya strictement aucune différence dans ce qu'on
produit. C'est comment on écrit qui change.
(Mais par contre comme MD est méga connu, ya des outils WYSIWYG pour MD
déjà codé, et ça c'est cool, ça permet d'avoir les deux d'un coup )
--
RastaPopoulos
Le mar. 21 mai 2019 à 14:47, RastaPopoulos <rastapopoulos@spip.org> a écrit :
Le 21/05/2019 à 10:00, Eric Lupinacci a écrit :
Et dans le genre, WYSIWYG c’est surement le mal absolu mais c’est
beaucoup plus inclusif que la syntaxe SPIP ou MD.Ce point est en bonne partie faux.
Surement si tu le dis…
Romy et d’autres ont bien montré qu’en fait le WYSIWYG avec plein de
boutons était plus compliqué pour plein de gens pour réellement rédiger
au quotidien et encore pire pour rédiger pour le web/le multi-support.
C’est même extrêmement pas accessible pour les gens avec des handicaps.
Pourquoi le WYSIWYG serait aussi boutonneux.
Est-ce que j’ai dit que j’aimais les 300 boutons de Word, non j’ai parlé d’un autre logiciel qui justement avait juste ce qu’il fallait.
Et oui Word est trop permissif pour être réellement efficace donc ce n’est pas ce qu’il faut reproduire mais j’ai connu mieux.
C’est surtout rassurant pour les gens qui ont appris à écrire avec Word,
mais donc c’est juste une question d’habitude, et non pas de qualité
intrinsèque de l’ergonomie (tout comme si t’as appris l’ordi sur Win,
t’es perdu quand tu passes à Ubuntu : ou l’inverse).
Oui mais ces gens se comptent par milliards…
Et tout le monde n’est pas enclin à apprendre et remettre en cause ses habitudes.
C’est un peu comme les outils et SPIP pour moi. Quand je rédige je m’attache au contenu et pas à ce qui me permet de le rédiger qui doit me permettre d’être plus efficace.
L’apprentissage c’est une contrainte à l’utilisation, il faut donc le minimiser pour inclure le plus de gens.
Bref, je pense que je suis d’une génération qui préfère une doc papier bien présentée avec un sommaire qui explique la logique de ce qu’on va lire plutôt qu’une longue page MD ou SPIP
Tu compares la lecture, avec l’écriture, donc euuuh…
Personne ne « lit » en SPIP ou MD…
Ben je sais pas mais quand j’écris en SPIP je lis pas le résultat mais du SPIP.
4 accolades pour dire gras c’est pas hyper intuitif sauf pour les initiés, pas plus que des * ou des _.
Pour ça l’éditeur CodIMD avec les deux fenêtres en regard est un plus indéniable.
Pour la lecture je parlais de la différence écran/impression, je me suis mal exprimé c’est vrai.
Quand je fais du word, je vois ce que je fais et j’imprime ce que je vois.
Quand je fais du SPIP ou du MD, je vois ou pas ce que j’écris mais quand j’imprime je n’ai pas une doc finalisée.
Les syntaxes légères servent à écrire sans avoir besoin d’enlever les
mains du clavier pour donner le sens des mots (bold etc), grace
justement à des caractères qu’on ajoute au fil du texte, sans devoir
cliquer sur 12 boutons. Après on génère exactement la même chose : des
docs numériques ou papiers avec un sommaire « qui explique la logique de
ce qu’on va lire », ya strictement aucune différence dans ce qu’on
produit. C’est comment on écrit qui change.
Humm c’est pas mon expérience.
(Mais par contre comme MD est méga connu, ya des outils WYSIWYG pour MD
déjà codé, et ça c’est cool, ça permet d’avoir les deux d’un coup
Oui ça c’est une bonne nouvelle je trouve.
Bon Dredi à tous
Bon mais mon mail était trop lourd il a été bloqué a l'envoie sur la liste,
Donc je le renvoie sans mise en forme en texte brut, déjà c'est pas en morse, c'est plus facile a lire.
j'ai essayé de répondre assez clair, sans trop dériver, sans vexer personne , ça m'a pris plus de temps et je sais même pas si j'ai réussit
Le 21/05/2019 à 10:00, Eric Lupinacci a écrit :
Hello,
Le mar. 21 mai 2019 à 07:29, GraphX <arnaud.berard@mister-graphx.com <mailto:arnaud.berard@mister-graphx.com>> a écrit :
Ca confirme rien du tout et j'ai l'impression que tu dit sans
savoir ou avoir même essayé (comme git ou pakagist/composer, …)
un peut ronchon quand c'est pas du made in spip quoi ^^ Comme
si des millions de devs ne pouvaient pas arriver à la cheville du
niveau de reflexion d'une dizaine de spipeur-se francophones,
autour d'un framapad et quelques echanges mails…Oui hier j'ai dit quelques conneries, je le reconnais sur la typo et la syntaxe MD.
Ca ne vaut pas je pense le procès d'intention que tu me fais sur Git, packagist, composer
Je ne fais pas de procés, je compare les deux, faisant un amalgame avec des légendes "urbaines" de choses dites sur IRC, dans des échanges, ce n'est pas toi qui est ciblé directement, mais plutôt un discours collectif, une rumeur persistante que certains propulse, véhicule, et basé sur des apriori surtout motivé par une peur du changement j'ai l'impression, (je n'ose pas me dire que c'est uniquement un intérêt personnel).
Et le tout de ces légendes urbaines, bloque l'évolution de la forge spip déjà appelons la comme on veux, ce n'est pas une barrière technique, mais plutôt un blocus technique, ça j'en suis certain car avec mon petit niveau j'ai répliqué un serveur de paquet privé n'utilisant que git et piochant dans github et gitlab... donc si moi j'y arrive c'est que c'est faisable.
Moi j'aime les nouveaux outils, les nouvelles libs, c'est noel quand je trouve un nouveau truc pour jouer avec ^^
je dis qu'on ne pourra plus/pas faire sans, et il faut essayer de comprendre le workflow qui est eprouvé par des dizaines d'autres cms, adopté par des millions de devs... (genre la pensée chinoise du Dredi "quand tout le monde est fou autour de toi, méfie toi, le fou c'est peut être toi" )
Et comme tu est plus "influenceur" que moi, core dev, j'essaye de te faire changer d'avis en me disant que si toi tu passe a des outils plus modernes, d'autres suivrons (…simple ^^ ne crois pas que je m'acharne sur toi lol j'estime ton travail à juste titre et je suis tes écris depuis que j'utilise spip ),
Donc oui je vais tenter de te faire changer d'avis (toi ou d'autres peut être) et au moins partager le mien
- on peut écrire des documentations complexes sur Git{hub|lab} et en faire des documentation finalisée, fonctionnelles et collaborativement.
- oui composer a des gros atouts comparé a l'outil actuel svp smart paquet
- oui git a de réels avantages comparé a svn
- au final oui le workflow proposé par les plateforme de type github/lab doit remplacer l'actuel vision de forge
- composer quand a lui est un gestionnaire package plus sur et fiable que l'actuel manière de gérer les paquets
je détaille et argumente ensuite mon avis et comment j'ai subit la transition, ce que j'en ai retenu.
ni le dédain sur les spipeurs francophones qui ne le méritent pas.
Je n'ai pas de dedain pour les francophones on m'as déjà taxé (entre autre) sur cette liste de :
developeur franchouillard ethno-centriste (j'ai appris un mot ce jour la )
mdr on est moins de francophones au niveau mondial donc forcément on se prive de l'ouverture avec les autres en ayant un outil privilégiant un public francophone (doc source, langage de boucles, fonction, api sont en français). Donc si on fait pareil avec les libs, les technos, les outils, … ne pas tourner en vase clos tel était mon propos.
Désolé si j'ai vexé des gens du coup, c'est une vérité vrai et je suis mm étonné d'avoir a me justifier sur ça
J'espère ne pas être celui qui bloque le développement de SPIP depuis 8 ou 10 ans, ça serait bien prétentieux...
Peut-être devrais-tu t'appliquer ce que tu me reproches: relis ce que j'écris, j'ai écrit et toutes les propositions que j'ai faites depuis des années, peut-être alors tu auras une vision plus exacte...
Je t'ai lu et je te lis avec attention , j'ai pas dit que tu bloquais le developpement, tu fait plutot avancer les chose, j'ai dit on en parle depuis 8 ans et sous entendu on entend encore les mm prégugés… je parlais plus de la forge spip zone que de spip en plus.
Après tu as tout a fait raison, je devrais commencer par me l'appliquer à moi même, moi aussi je suis passé a tout git y'a que 1 an réellement alors que déjà les developpeurs de ma boite il y'a presque 9 ans me disait de passer a mercurial ou git,que svn c'était has-been.
Mais entre temps j'ai changé tout mon workflow d'intégration, ré-écris mon framework css, tout passé a scss, créé un outil pour le documenter, passé a node + gulp pour compiler le tout, utiliser yarn + eyeglass pour gérer les dépendances de mes composants scss, ça m'as pris du temps … et j'ai finis par git alors que j'aurais peut être du commencer par ça.
https://gitlab.com/mister-graphx/fragments/Builder
https://gitlab.com/mister-graphx/fragments/framework
https://gitlab.com/mister-graphx/frontdoc + https://gitlab.com/mister-graphx/little
La depuis quelques semaines je travail avec composer, sur un projet php utilisant principalement des composants symfony et donc j'ai eut l'occasion de me remettre a composer, en allant plus loin, et effectivement oui si je pouvais organiser mes distribs spip aussi surement , rapidement , ce serait mieux.
Après si on en revient à MD, l'expérience récente m'a un peu déçu avec les tableaux, les guillemets et certaines listes (je me rappelle plus exactement le cas).
Mais je te rassure c'est la même chose avec SPIP.
Je pense que je suis 20 à 30% plus efficace pour rédiger une documentation correctement typographiée et présentée avec Word ou Google Docs qu'avec SPIP ou MD.
Le problème des traitement de texte, que j'ai vu et aussi avec la syntaxe spip, c'est que les gens utilise un h1 parce-qu’il est plus gros, ou un h2 parce-que dans la charte il est centré : et ça c'est la cata !! (y'a des dizaines d'articles a ce sujet)
Alors oui quelqu'un-e qui utilise les titres correctement et qui sait ce qu'il-elle fait, le problème du traitement de texte c'est que ça parait simple et les gens font du joli :
- ET c'est pas leur job : leur job c'est de fournir un contenu (déjà c'est parfois dur) rédigé et structuré
d'ou le fait que le plugin intertitre affiche les balises utilisées H1,H2
Un doc correctement structuré il devrait n'utiliser que
- titres h1 a h6
- bold,italic,cite
- paragraphe
- listes
et c'est tout , donc en markdown y'a pas de syntaxe compliqué a retenir c'est ce qui est autorisé généralement dans les blocs texte des page builder, et ça suffit pour faire un plan sémantiquement correcte (c'est surement pour ça que c'est ce qui est livré en raccourcis standard avec spip hors titres).
mm j'aime bien que les documents ne soit pas inclus dans le texte mais juste en référence, on incorpore après, en plus ça m'évite d'exporter l'image pour la traiter ensuite.
Pour googleDoc j'utilise j'en conviens, uniquement car on peut discuter autour du doc et que les gens sont habitués a word, mais si tu exporte en html pour le publier a un moment :
- le markdown restera plus propre car c'est fait pour générer du html valide.
- Word OpenOffice génère du html pas terrible et difficilement utilisable ensuite hors papier.
Autre avantage, un article rédigé au format markdown sera donc publiable dans quasi tout les cms ou dans un générateur de site statiques, ou un espace gitLab-pages gitHub-pages, ou sur dropbox paper aussi je crois.
bon je viens de l'imprimerie/compo donc nous c'était ça un doc, maintenant les gens mélange la mise en forme et le traitement des contenus résultat faut récupérer des images plus ou moins abimées par le soft, ou se trimbaler un doc qui pèse un poids monstrueux car les images sont trop lourdes et embarquées dedans.
Et il faut un logiciel du coup pour pouvoir utiliser les révisions d'un document, et envoyer par mail genre doc_v1, doc_v1b, doc, ou sinon dropbox qui as un suivi de version mais pas de diff je crois juste un etat a une date.
J'utilise un traitement de texte pour faire un courrier en somme => c'est fait pour ça, y'a des logiciels pour la mise en page.
Et encore j'utilise les traitements de texte depuis bien 30 ans et en 1995 j'ai utilisé un logiciel sur SUN à Alcatel qui s'appelait Alice avec lequel tu ne pouvais pas faire un doc pourri; jamais je n'ai retrouvé un logiciel de cette efficacité.
Bref, je pense que je suis d'une génération qui préfère une doc papier bien présentée avec un sommaire qui explique la logique de ce qu'on va lire plutôt qu'une longue page MD ou SPIP. On ne se refait pas.
Oui sur le web c'est déconseillé de faire de long articles, et en rédaction commencer par l'index / plan
y'a t'il besoin d'un wysiwig pour comprendre la hiérarchie la : Honnêtement je comprends mieux la hiérarchie en regardant le code que le rendu…
# Maintenir un mutualisation avec Git
## Quelle stratégie , mono-repo ou multi ?
## Sur le serveur
### Initialisation/création du dépot
### Mise a jour des plugins
## En local
- l'importance des niveaux de titres correctement imbriqués pour générer un index automatique et une navigation dans l'article, le truc qui m'as fait adopter markdown très vite,
- De ne pas faire des articles interminables : comme c'est le cas actuellement sur contrib par exemple, ou on a un article pour toute la doc dans 95% des cas (je critique rien c'est un constat) Ce qui au final reviens pour moi a un readme stocké dans une base de donnée, pour pouvoir être éditable.
- Beaucoup d'outils markdown te propose un index automatique basé sur les niveaux de titre.
Et dans le genre, WYSIWYG c'est surement le mal absolu mais c'est beaucoup plus inclusif que la syntaxe SPIP ou MD. Et si MD permet de faire que le WYSIWYG passe du coté clair de la force c'est une très bonne raison pour y passer (sur CodIMD l'éditeur avec la syntaxe à gauche et le rendu à droite est très efficace et rassurant, mais il faut une page assez large pour ça... :p).
ça c'est le point fort, les outils autour de la syntaxe markdown , comme c'est très utilisé, y'a pleins de trucs: après de la a avoir un vrai wysiwig, ça existe mais je sais pas si ça me serait utile, je me concentre plus en mode texte que en mode mise en forme. Sur mac j'avais acheté LightPaper qui est pas mal (y'a un sommaire auto), mais je l'utilise quasiment plus tu pouvais spéciifer la css de ton site pour avoir la preview quasi réelle.
A tester par exemple atom sans aucun addons supplémentaires ça fait un super éditeur markdown avec la preview à droite ou en bas, ou tu veux (clic droit copier au format html, enregistre au fromat html ^^), la coloration (titres, gras), des snippets,
Et la (je te cherche ^^) tu combine la rédaction de doc + git qui est intégré aussi en natif
ça gère les état git de tes fichiers avec les lignes, la diff, … tu peut citer une discussion ou un projet dans ton commit ça te fait les liens, et la personne concerné reçoit un mail pour aller lire , voire et donner son avis (sur GitLab en tous cas). d'ou le fait que je suis pas fan des framapad,vox et autres, la autour d'un fichier texte y'a des issues, des discussions, un suivi dans une seule interface.
Donc sans addons sans quitter ton éditeur (en admettant que tu ai déja cloné la doc v1 en local ^^ sinon y'a un git clone a faire)
Scénario :
- Tu peut créer une branche locale de ta doc : prepare v2 (depuis ton éditeur - 1clic il te crée la branche)
- revenir instantanément sur la doc de la v1 pour corriger un truc rapide (depuis ton éditeur - 1clic, il bascule l'état des fichiers instantanément car avec git tu as a dispo en local)
- quand t'as suffisament avancer ta doc prepare v2 et que c'est montrable la tu décide de pousser la branche sur le dépot et de commencer a discutter autour (1 clic ) et dans ton commit tu cite les gens, les issues (mail et taches sont automatiquements assignées)
- A ce moment on t'apelle et on te dis ha la doc v1 y'a une boulette, hop tu repasse en v1 toujours depuis ton éditeur et tu corrige, tu envoie direct.
- la tu raccroche et tu repasse en branche doc v2 (toujour 1 clic depuis ton éditeur) en priant pour que durant 5min tu puisse continuer ton boulot sur la v2 sans qu'on te prenne le choux avec la v1 ^^.
Compliqué ?
la avec svn si on veut faire la même **pour moi** c'est pas aussi simple, et surtout pas aussi rapide car svn ne stoque rien en local donc tu rapatrie tout a chaque fois, lourd, et long.
et avec un traitement de texte : c'est pas collaboratif, aucun suivi ou difficile, pas de diff, pas de discussion autour, pas de notifications auto, etc …
Pour les autres calomnies ;-), Git et Composer.
Je n'ai rien contre, bien au contraire parce qu'il semble que ce soit un passage obligé pour que certains s'intéressent ou se ré-intéressent à SPIP.
se ré-intéresser au travail collaboratif sur l'espace de la zone serait plus juste … spip et les plugins existe en dehors , je ne dépose que très peut de projets sur spip-zone, je ne suis pas le seul … ça dépend si on utilise svp, si on a un serveur de paquet privé, comment on installe ses site et si on les met a jour via git, …
Mais il ne faut pas que cela exclut d'autres contributeurs avec des profils moins "dev".
Tout a fait chacun a son niveau, toute remarque ou contribution, correction typo ou autre est bonne, c'est pas pour autant que cette contribution ne doit pas être validable, suivie, discuttée avant d'être publiée et incorporé au paquet, c'est la l'avantage des interface gitea, github, gitlab et du workflow qu'ils propose.
Le truc c'est que quand on parle de pull-request, fork j'ai l'impression que c'est un gros-mot ? (humour encore hein ^^)
Moi ça me parait plutôt sain comme démarche :
> bonjour je suis pas dev, mais j'ai vu que dans la chaine de langue y'avait ça > pull request
>> oui c'est cool mais t'as oublié une virgule dans ton array ça pete tout : essaye encore
> j'ai corrigé la virgule > pull request
>> cool , merci : < merged
Non ? y'a tout la : relaxité, méthode , souplesse
Pour moi, qui suit un spipeur occasionnellement assidu mon but est de créer de la fonctionnalité et de ne pas perdre de temps sur les outils.
Ce type de changement doit être accompagné c'est tout.Donc depuis quelques jours j'ai réactivé mon github, j'utilise Git/Github suivant l'ordi.
Je reste sur ma position initiale : Git fait tout et même le reste et c'est quand même une usine à gaz alors qu'on en utilise qu'une infime partie la plupart du temps.
Mais si on détoure bien son environnement on arrive à reproduire le checkout/commit/update de SVN qui suffit dans 95% des cas et des utilisateurs.
Je suis très fan par contre de Github et de son desktop qui arrive bien à faire émerger l'essentiel de git assez simplement.
J'ai utilisé au début de mon passage, maintenant c'est intégré a tous les éditeurs de texte comme expliqué précédement avec branches locales etc, les commande que je doit taper dans le terminal c'est git remote … git push origin quand j'initialise le dépot le reste se fait depuis l'éditeur de texte quasiment, ou sur le site du dépot (merge).
Avant j'utilisais smart-svn, depuis que je suis passé a Git c'est depuis mon éditeur ou terminal
A noter aussi que un terminal comme iTerm a quand mm l'auto-completion de commande, donc tu ne les tapera qu'une fois ensuite quand tu tape git il te suggère toute les commandes que tu as déjà utilisé… (même les mauvaise ^^)
Pour SPIP et son écosystème de plugins, le git SPIP, Gitea, etc, je suis plus dubitatif, je trouve Github plus facile d'accès mais c'est peut-être un point de vue subjectif.
J'utilise gitHub, mais j'ai finalement choisit gitLab pour mes projets :
- les projets > sous projets son plus pratiques, plus souple que sur GitHub,
- l'interface est traduite en français pour les clients qui prefère tiket que issue
- pas aussi user friendly que github mais je trouve plus puissant sur certains point, notamment le WebIDE (utile pour le non dev qui veux éditer un readme), les liens auto, les snippets par projet ou globaux , la syntaxe et les possibilités markdown ^^ etc … franchement je recommande …
Je peux dire qu'aujourd'hui je suis aussi presque aussi efficace en Git qu'en SVN (j'ai pas refait mon petit script svn de mise à jour de mes sites de dev) mais cela ne m'apporte rien de plus pour l'instant.
je suis plus productif avec Git et surtout plus sécure, ça m'a obligé a passer a une organisation plus cohérente et plus sure finalement.
Ce que ça m'apporte :
- créer des branches locales indépendantes du dépot si besoin, et pouvoir switcher de l'une a l'autres rapidement pendant mon travail, sans quitter mon projet.
- pouvoir fusionner mes branches locales si besoin, revenir sur une modif, tester avant de pousser sur le depot
Idem sur le serveur, on peut switcher d'une branche a l'autre beaucoup plus vite sans tout re checkout
Le fait que ce soit natif dans mon éditeur m'as fait gagné du temps aussi, du confort, gagné de la ressource et mémoire en utilisant une appli en moins, mais ça c'est pas relatif directement a git…
Composer c'est plus compliqué pour moi.
Déjà je pige pas trop le système dans son ensemble, et j'ai surtout du mal à entrevoir le lien entre le dev et la production.
C'est simple ça remplacerais une partie au moins de svp pour l'install, et smartpaquet pour les service pakagist . C'est idem que Yarn ou npm mais pour le php (ça tout le monde à compris ^^)
Chaque plugin est un pakage, qui peut requerir d'autres paquets, et ton appli est un paquet qui va requerir des paquets ^^
Jusque la, tu me dis et alors svp ça fait pareil mais c'est des paquets et pas des packages !!
C'est pas faux, Mais non … Chacun des requis pouvant etre défini par un
- namespace : une version
une version = un tag git sur le dépot pakagist, ou sur un depot local, ou si tu définie des repos vcs c'est traduit en une url vers un repo.
LA différence c'est que composer s'appuie sur un etat git/svn plutot que sur un numéro de version dans le paquet (considéré comme très aléatoire … cf la doc de composer)
Donc tu gère ultra finement toute les dépendances et leur imbrications, avec l'assurance d'un état instantané sur le dépot.
Ce n'est pas le cas du gestionnaire de paquet de spip ni de svp
Après il a d'autre avantages, comme le .gitattributes qui te permettra de ne pas installer la doc ou les test en prod , etc
Ma seule alerte concerne le référentiel des plugins qui tourne autour des XML et de smart-paquets.
Smart paquet n'as plus vraiment d'utilité si tu passe par composer, on passe pas par des zip on installe des sources depuis un dépot git/svn, c'est le point fort, ainsi que aussi un cache qui te permet de pas tout re-checkout a chaque install.
Après c'est créer un pakagist like pour spip ou utiliser pakagist
SVP pourrait devenir une interface de composer, je sais pas comment c'est fait chez Drupal faut regarder, ils utilise symfony donc composer + yarn pour le front
Je dis juste attention, il faut préserver notre capacité à alimenter Plugins SPIP/Contrib surtout qu'on est en train de le refondre pour le rendre plus accessible et performant.
Super chantier, y'aura des issues/tikets ? ça va apporter juste la doc ou des outils pour faciliter les développement et le suivi de bug SAD ?
J'ai toujours soutenu l'idée que (mais la aussi je sais que je passe pour un extra-terrestre,ou un débile quand je dis ça)
- sur pakagist, npm, etc y'a le readme d'affiché ^^ en toute simplicité et toutes les infos possibles (tags, depot, mainteneur, dependances, dependances de dev, )
- c'est plus facile pour le mainteneur-euse d'avoir tout dans le même dépot la doc , le source… y'a github-page ou git-lab-pages , ça aussi c'est que du bonus
Exemple :
Le dépot https://github.com/mistergraphx/TW5_GX_edition
La doc : https://mistergraphx.github.io/TW5_GX_edition/
Pas de cout de maintenance, gratos, pas de cout serveur, pas de cout humain c'est clair, propre, rapide
J'ai une branche doc dans le dépot, une master, je change de branche en local, je fait --build, je commit , et la doc est a jour
2 clics 1 commit une ligne de commande
Et c'est de plus la structure recommandée d'un dépot chez composer, npm, etc
Voilà.
Quand je relis ce mail ça me déprime de devoir me justifier sur tout ça.
Je me demande si il n'est pas là, le vrai problème de SPIP.
Mais tu n'as pas a te justifier, je tiens le débat car toi on t'écoute ^^ tu rédige et depuis longtemps, tu contribue énormément, comme dit au début … un influenceur, moi je suis un nain-posteur ^^ (rapport aux mails et forums)
Je te convaincrais pas en un jour, je pense
++
Eric (qui fatigue et déprime un peu).
Bises et déprime pas
----
spip-zone@rezo.net -https://listes.rezo.net/mailman/listinfo/spip-zone
--
Bonne journée
Arnaud B. (Mist. GraphX)
Le 20/05/2019 à 10:28, Cerdic a écrit :
Je fais un nouveau fil parce que les discussions partent dans tous les sens, mais je réagis à 2 mails de JLuc et Eric sur le fil des catégories de plugin.
J'ai reporté les liens et tenté une synthèse de ces fils sur la page
https://contrib.spip.net/convertir-spip-en-md
bisous
JL
JL disait :
> Au passage, le rapprochement avec github va donner de plus en plus envie aux développeurs d'utiliser md.
>
> Dans la logique d'immersion des singularités de SPIP dans le grand bain mondialisé d'inter-développements php,
il sera utile de disposer d'un convertisseur raccourcis-SPIP vers l'un des dialectes md le plus approprié.Je sais pas si c’est un outil de conversion dont on a besoin ou si c’est de passer vraiment à MD, c’est une vraie question.
Mais pour la conversion on peut soit faire SPIP -> HTML -> MarkDown (il y a une lib MarkDownify que j’utilise dans Newsletters pour générer les versions texte qui marche pas mal)
Soit effectivement écrire un outil de conversion, peut-être en adaptant les wheels de TextWheel pour générer du MD au lieu du HTML, mais peut-être plus simplement en faisant de la substitution de raccourcis, à voirEric disait lui:
> Il existe déjà un plugin Markdown pour écrire en md dans SPIP mais je ne sais pas si il fait à aussi une fonction d'export spip vers md.
> Maintenant, j'ai expérimenté md depuis quelques temps, c'est bien... limité.
> J'espère que ce n'est pas la voie qu'on prend…Je pense au contraire que c’est bien la voie qu’il faudrait prendre. Quelles sont les limites que tu trouves ? Un peu de retex serait bien utile.
Tu parles du MD natif basique, dans un éditeur desktop, ou de l’utilisation de MD dans SPIP avec le plugin SPIP ?
Pour info le plugin SPIP permet d’utiliser MD, en continuant à utiliser les raccourcis de lien SPIP, les notes de bas de page SPIP, et les modèles SPIP.Je ne sais vois pas trop à quelles limites tu fais allusion…
--
Cédric----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
Hello,
N’oubliez pas l’étude comparée des deux syntaxes que j’avais faite :
http://romy.tetue.net/syntaxe-spip-versus-markdown
À retenir : absence de recouvrement des syntaxes : aucun raccourci SPIP ne sert à autre chose dans Markdown et réciproquement.
Si ça peut aider la réflexion
Le 10 juin 2019 à 09:45, JLuc <jluc@no-log.org> a écrit :
Le 20/05/2019 à 10:28, Cerdic a écrit :
Je fais un nouveau fil parce que les discussions partent dans tous les sens, mais je réagis à 2 mails de JLuc et Eric sur le fil des catégories de plugin.
J'ai reporté les liens et tenté une synthèse de ces fils sur la page
https://contrib.spip.net/convertir-spip-en-mdbisous
JLJL disait :
Au passage, le rapprochement avec github va donner de plus en plus envie aux développeurs d'utiliser md.
Dans la logique d'immersion des singularités de SPIP dans le grand bain mondialisé d'inter-développements php,
il sera utile de disposer d'un convertisseur raccourcis-SPIP vers l'un des dialectes md le plus approprié.
Je sais pas si c’est un outil de conversion dont on a besoin ou si c’est de passer vraiment à MD, c’est une vraie question.
Mais pour la conversion on peut soit faire SPIP -> HTML -> MarkDown (il y a une lib MarkDownify que j’utilise dans Newsletters pour générer les versions texte qui marche pas mal)
Soit effectivement écrire un outil de conversion, peut-être en adaptant les wheels de TextWheel pour générer du MD au lieu du HTML, mais peut-être plus simplement en faisant de la substitution de raccourcis, à voir
Eric disait lui:Il existe déjà un plugin Markdown pour écrire en md dans SPIP mais je ne sais pas si il fait à aussi une fonction d'export spip vers md.
Maintenant, j'ai expérimenté md depuis quelques temps, c'est bien... limité.
J'espère que ce n'est pas la voie qu'on prend…Je pense au contraire que c’est bien la voie qu’il faudrait prendre. Quelles sont les limites que tu trouves ? Un peu de retex serait bien utile.
Tu parles du MD natif basique, dans un éditeur desktop, ou de l’utilisation de MD dans SPIP avec le plugin SPIP ?
Pour info le plugin SPIP permet d’utiliser MD, en continuant à utiliser les raccourcis de lien SPIP, les notes de bas de page SPIP, et les modèles SPIP.
Je ne sais vois pas trop à quelles limites tu fais allusion…
--
Cédric
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
-- tetue
Je prend la discussion au vol, avec beaucoup de retard
Le lun. 20 mai 2019 à 11:41, JLuc a écrit :
Le 20/05/2019 à 11:17, Eric Lupinacci a écrit :
Hello,
Le lun. 20 mai 2019 à 10:28, Cerdic <cedric@yterium.com mailto:[cedric@yterium.com](mailto:cedric@yterium.com)> a écrit :
Je sais pas si c’est un outil de conversion dont on a besoin ou si c’est de passer vraiment à MD, c’est une vraie
question.Si SPIP passe natif en md, les anciens raccourcis pourront resteront compréhensibles
(ou en natif comme avec le plugin md actuellement ou en option ou en plugin)
mais pour ne pas disperser les efforts de développement et maintenance,
et bénéficier aussi de tous les devs autour de md
il y aura intérêt rapidement à pouvoir convertir les textes historiques des sites historiques
au format raccourcis en format md.
Je ne sais plus avec qui j’avais eu ce genre de discussion il y a bien des mois, mais mon avis est que la syntaxe de marquage/balisage devrait être géré par plugins… Et que les différentes tables devraient avoir un champ « syntaxe » (ou « format » ? mais je trouve ce mot plus ambigu) dont la valeur serait par défaut « spip » (du moins pour les anciennes installations et en dehors de tout autre plugin, et donc pas besoin de convertir avec le risque de ne pas arriver à prendre en compte les personnalisations). On pourra alors proposer du Markdown ou du Restructuré au même du WikiCreole pourquoi pas ?
Oui attention je parle de mon expérience qui est somme toute limitée avec quelques éditeurs online (CodIMD) et desktop.
La grosse limitation je l’ai vu dans les tableaux où c’est hyper basique : il faut toujours un titre, pas de colspan…Parmi les dialectes md, je suis tombé sur le multimarkdown qui a une syntaxe enrichie
https://rawgit.com/fletcher/MultiMarkdown-6-Syntax-Guide/master/index.html
http://fletcher.github.io/MultiMarkdown-4/et qui permet les colspans : http://fletcher.github.io/MultiMarkdown-4/tables
Il me semble que MultiMarkdown, sauf si je confons, est une tentative de fusion rationelle des divers dialectes prédominants… En tout cas, contrairement à ce qu’on peut penser, Markdown est de base très très limité ; et les diverses extensions que j’ai vu ne sont pas entièrement compatibles entre elles, et pourtant aucune n’a vraiment tord dans son interprétation (ça me rappelle la glorieuse époque du BASIC)
En fait, SPIP a été fait pour rédiger du contenu « journalistique » et j’ai l’impression que md est plus fait pour rédiger
du contenu technique.
Oui c’est mon impression aussi, mais les dialectes permettent visiblement plus que la seule doc technique.
Je ne crois même pas que Md ait été conçu dans l’idée de la doc technique (je dirai même que c’était juste une belle synthèse des différentes manière de faire du pure texte dans les mails et les lisez-moi de logiciels) Mail il est vrai que les extensions faites, essentiellement par et pour les forges de codes, ont été pour pallier des manques techniques.
Je suis cependant resté sur ma faim même dans ce cas (doc technique) où j’arrivais à faire mieux avec d’autres balisages.
Le lun. 10 juin 2019 à 12:50, tetue@rezo.net a écrit :
Hello,
N’oubliez pas l’étude comparée des deux syntaxes que j’avais faite :
Merci pour cette comparaison complète.
J’y ai retrouvé certaines de mes déceptions Markdown (par exemple les ancres et les notes de bas de page, les liens d’images bien compliqués et le paragraphe indenté qui se transforme en bloc de code…)
Noter que pour les listes, il n’est pas nécessaire de tabuler, mais d’utiliser 2/3/4 blancs (par contre il faut rester cohérent, comme pour le langage Python ou le YAML, sinon le programme d’interprétation derrière peut s’y perdre). Bon, ce n’est pas toujours accessible/évident dans une fenêtre web (mais très agréable quand on peut utiliser son éditeur de texte)
À retenir : absence de recouvrement des syntaxes : aucun raccourci SPIP ne sert à autre chose dans Markdown et réciproquement.
Excellente remarque ! Il serait potentiellement possible d’unir les deux mondes au lieu de juste vouloir migrer de l’un (riche et complet) à l’autre.
Si ça peut aider la réflexion
Le 10 juin 2019 à 09:45, JLuc <jluc@no-log.org> a écrit :
Le 20/05/2019 à 10:28, Cerdic a écrit :
Je fais un nouveau fil parce que les discussions partent dans tous les sens, mais je réagis à 2 mails de JLuc et Eric sur le fil des catégories de plugin.
J’ai reporté les liens et tenté une synthèse de ces fils sur la page
https://contrib.spip.net/convertir-spip-en-mdbisous
JLJL disait :
Au passage, le rapprochement avec github va donner de plus en plus envie aux développeurs d’utiliser md.
Dans la logique d’immersion des singularités de SPIP dans le grand bain mondialisé d’inter-développements php,
il sera utile de disposer d’un convertisseur raccourcis-SPIP vers l’un des dialectes md le plus approprié.
Je sais pas si c’est un outil de conversion dont on a besoin ou si c’est de passer vraiment à MD, c’est une vraie question.
Mais pour la conversion on peut soit faire SPIP → HTML → MarkDown (il y a une lib MarkDownify que j’utilise dans Newsletters pour générer les versions texte qui marche pas mal)
Soit effectivement écrire un outil de conversion, peut-être en adaptant les wheels de TextWheel pour générer du MD au lieu du HTML, mais peut-être plus simplement en faisant de la substitution de raccourcis, à voir
Eric disait lui:
Il existe déjà un plugin Markdown pour écrire en md dans SPIP mais je ne sais pas si il fait à aussi une fonction d’export spip vers md.
Maintenant, j’ai expérimenté md depuis quelques temps, c’est bien… limité.
J’espère que ce n’est pas la voie qu’on prend…
Je pense au contraire que c’est bien la voie qu’il faudrait prendre. Quelles sont les limites que tu trouves ? Un peu de retex serait bien utile.
Tu parles du MD natif basique, dans un éditeur desktop, ou de l’utilisation de MD dans SPIP avec le plugin SPIP ?
Pour info le plugin SPIP permet d’utiliser MD, en continuant à utiliser les raccourcis de lien SPIP, les notes de bas de page SPIP, et les modèles SPIP.
Je ne sais vois pas trop à quelles limites tu fais allusion…
–
Cédric
Le mar. 11 juin 2019 20:05, j’ai tapuscrit :
Je prend la discussion au vol, avec beaucoup de retard
Le lun. 20 mai 2019 à 11:41, JLuc a écrit :
[…]
Oui attention je parle de mon expérience qui est somme toute limitée avec quelques éditeurs online (CodIMD) et desktop.
La grosse limitation je l’ai vu dans les tableaux où c’est hyper basique : il faut toujours un titre, pas de colspan…Parmi les dialectes md, je suis tombé sur le multimarkdown qui a une syntaxe enrichie
https://rawgit.com/fletcher/MultiMarkdown-6-Syntax-Guide/master/index.html
http://fletcher.github.io/MultiMarkdown-4/et qui permet les colspans : http://fletcher.github.io/MultiMarkdown-4/tables
Il me semble que MultiMarkdown, sauf si je confons, est une tentative de fusion rationelle des divers dialectes prédominants…
Confusion ; je pensais à CommonMark qui essaie de faire un boulot comparable à WikiCreole (maintenant supporté par tout wiki qui se respecte, en plus de son propre dialecte) https://commonmark.org/
En tout cas, contrairement à ce qu’on peut penser, Markdown est de base très très limité ; et les diverses extensions que j’ai vu ne sont pas entièrement compatibles entre elles, et pourtant aucune n’a vraiment tord dans son interprétation (ça me rappelle la glorieuse époque du BASIC)
En fait, SPIP a été fait pour rédiger du contenu « journalistique » et j’ai l’impression que md est plus fait pour rédiger
du contenu technique.
Oui c’est mon impression aussi, mais les dialectes permettent visiblement plus que la seule doc technique.Je ne crois même pas que Md ait été conçu dans l’idée de la doc technique (je dirai même que c’était juste une belle synthèse des différentes manière de faire du pure texte dans les mails et les lisez-moi de logiciels) Mail il est vrai que les extensions faites, essentiellement par et pour les forges de codes, ont été pour pallier des manques techniques.
Je suis cependant resté sur ma faim même dans ce cas (doc technique) où j’arrivais à faire mieux avec d’autres balisages.
Tiens, en lisant la « page d’intro à RTD » <https://docs.readthedocs.io/page/intro/getting-started-with-sphinx.html> ; j’ai suivi le lien vers un « billet d’Eric Holscher en mars 2016 » <http://www.ericholscher.com/blog/2016/mar/15/dont-use-markdown-for-technical-docs/> qui remarquait justement que MD est d’une part limité pour la doc technique (n’ayant pas été pensé pour cela, comme .rst et .adoc, on se retrouve à devoir rajouter du balisage HTML ci et là) et d’autre part trop mal spécifié (ce qui a conduit à diverses saveurs qui sont en fait des dialectes incompatibles) pour être valable pour de la documentation longue (ça convient bien comme remplaçant du BBcode pour les commentaires) et sur du long terme pérennement (les incompatibilités des différentes saveurs font qu’on se retrouve coincé pour convertir)
Le 20/05/2019 à 10:28, Cerdic a écrit :
Hello,
Je fais un nouveau fil parce que les discussions partent dans tous les
sens, mais je réagis à 2 mails de JLuc et Eric sur le fil des
catégories de plugin.
(…)
Pour info le plugin SPIP permet d’utiliser MD, en continuant à
utiliser les raccourcis de lien SPIP, les notes de bas de page SPIP,
et les modèles SPIP.
Salut,
je sais pas trop où le signaler, mais le balisage <md> du plugin
Markdown semble incompatible avec l'option d' "Amélioration
typographique des abréviations avec exposants" du plugin OrthoTypo.
Concrètement, si l'option est activée, le d de la balise <md> passe en
exposant, et le texte en Markdown n'est plus traité.
Testé avec un Spip et des plugins à jour, et en local sur un site avec
uniquement les deux plugins.
(merci pour ces super plugins !)
++
--
Cédric----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
C’est manifestement orthotypo qui faute et ne devrait pas faire un tel remplacement !
--
Cédric
Le 27 oct. 2019 à 10:52 +0100, ari <ari@rebellyon.info>, a écrit :
Le 20/05/2019 à 10:28, Cerdic a écrit :
> Hello,
>
> Je fais un nouveau fil parce que les discussions partent dans tous les
> sens, mais je réagis à 2 mails de JLuc et Eric sur le fil des
> catégories de plugin.
>
(…)> Pour info le plugin SPIP permet d’utiliser MD, en continuant à
> utiliser les raccourcis de lien SPIP, les notes de bas de page SPIP,
> et les modèles SPIP.Salut,
je sais pas trop où le signaler, mais le balisage <md> du plugin
Markdown semble incompatible avec l'option d' "Amélioration
typographique des abréviations avec exposants" du plugin OrthoTypo.Concrètement, si l'option est activée, le d de la balise <md> passe en
exposant, et le texte en Markdown n'est plus traité.Testé avec un Spip et des plugins à jour, et en local sur un site avec
uniquement les deux plugins.(merci pour ces super plugins !)
++
>
>
> --
> Cédric
>
> ----
> spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
La version 1.5.0 devait corriger ça sans autre bug si j’ai rien cassé 
--
Cédric
Le 27 oct. 2019 à 10:52 +0100, ari <ari@rebellyon.info>, a écrit :
Le 20/05/2019 à 10:28, Cerdic a écrit :
> Hello,
>
> Je fais un nouveau fil parce que les discussions partent dans tous les
> sens, mais je réagis à 2 mails de JLuc et Eric sur le fil des
> catégories de plugin.
>
(…)> Pour info le plugin SPIP permet d’utiliser MD, en continuant à
> utiliser les raccourcis de lien SPIP, les notes de bas de page SPIP,
> et les modèles SPIP.Salut,
je sais pas trop où le signaler, mais le balisage <md> du plugin
Markdown semble incompatible avec l'option d' "Amélioration
typographique des abréviations avec exposants" du plugin OrthoTypo.Concrètement, si l'option est activée, le d de la balise <md> passe en
exposant, et le texte en Markdown n'est plus traité.Testé avec un Spip et des plugins à jour, et en local sur un site avec
uniquement les deux plugins.(merci pour ces super plugins !)
++
>
>
> --
> Cédric
>
> ----
> spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
Le 27/10/2019 à 13:10, Cerdic a écrit :
La version 1.5.0 devait corriger ça sans autre bug si j’ai rien cassé
Merci !
autre petit bug repéré au moment de rédiger une petite doc : la balise
<md> ne peut pas être mise entre balises <code></code>.
<code><md>…</md></code> donne <span class="base64mdblocs"
title="PG1kPuKApjwvbWQ+"></span>
--
Cédric
Le 27 oct. 2019 à 10:52 +0100, ari <ari@rebellyon.info>, a écrit :Le 20/05/2019 à 10:28, Cerdic a écrit :
Hello,
Je fais un nouveau fil parce que les discussions partent dans tous les
sens, mais je réagis à 2 mails de JLuc et Eric sur le fil des
catégories de plugin.(…)
Pour info le plugin SPIP permet d’utiliser MD, en continuant à
utiliser les raccourcis de lien SPIP, les notes de bas de page SPIP,
et les modèles SPIP.Salut,
je sais pas trop où le signaler, mais le balisage <md> du plugin
Markdown semble incompatible avec l'option d' "Amélioration
typographique des abréviations avec exposants" du plugin OrthoTypo.Concrètement, si l'option est activée, le d de la balise <md> passe en
exposant, et le texte en Markdown n'est plus traité.Testé avec un Spip et des plugins à jour, et en local sur un site avec
uniquement les deux plugins.(merci pour ces super plugins !)
++
--
Cédric----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone