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.
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, à 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…
Le lun. 20 mai 2019 à 10:28, Cerdic <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.
Oui c'est la 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
Oui ça peut être une idée effectivement.
Maintenant cette conversion c'est pour une migration future parce que sinon
je n'en vois pas trop l'intérêt ?
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…
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...
Il y a aussi des choses très pratiques comme la titraille voire les listes.
Après on a quand même un maximum de raccourcis et d'amélioration typo qui
me semble ne pas exister dans md.
Alors peut-être qu'on peut faire comme avec SPIP évoluer les raccourcis
avec des wheels mais ne risque t-on pas d'avoir un md++ qui soit tellement
éloigné de celui qui est couramment utilisé qu'on en perdra l'intérêt ?
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.
Mais c'est peut-être qu'une perception faussée par mon utilisation limitée.
Tu as quoi comme vision md-SPIP ? Après on peut faire un benchmark plus
précis.
Le lun. 20 mai 2019 à 10:28, Cerdic <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.
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...
Tu as quoi comme vision md-SPIP ? Après on peut faire un benchmark plus précis.
++
Eric
Moi ça me va, comme spec markdown
ça permet d'ecrire des documentations ou articles assez "complexes" je trouve , en tous cas actuellement faut une dizaine de plugins pour faire ça en spip (et encore).
Le lun. 20 mai 2019 à 11:41, JLuc <jluc@no-log.org> a écrit :
Le 20/05/2019 à 11:17, Eric Lupinacci a écrit :
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.
Oui mais c’est ça, il existe des dialectes.
Mais encore faut-il qu’ils soient supportés par les outils.
CodIMD est très frustre lui et supporte le core de MD et je trouve ça notablement insuffisant.
C’est bien le problème.
ça permet d’ecrire des documentations ou articles assez « complexes » je
trouve , en tous cas actuellement faut une dizaine de plugins pour faire
ça en spip (et encore).
Ouais mais le problème c’est pas les plugins pour ajouter ou pas des typos.
Mais si tu regardes cette spec elle te convient car elle est spécifiquement très orientée vers la doc technique je suppose.
Je ne suis pas sur que mettre du code, des diff et du git est un sujet pour un journal ou un site éditorial ?
Ca confirme un peu ce que je dis.
CodIMD est très frustre lui et supporte le core de MD et je trouve ça
notablement insuffisant.
Non CodiMD supporte GFM (github flavoured markdown) qui est donc une
extension (la plus connue, la plus utilisée au monde, donc ça va…).
Et ils ajoutent en plus plein plein d'interprétation de code (mais là
c'est dans les ```) avec des choses pour faire des schémas etc.
À part les tableaux, je ne vois pas trop non plus. Je ne vois pas en
quoi SPIP aurait "plein" de choses en plus, c'est plutôt l'inverse.
Faudrait maintenir un tableau comparatif pour y voir plus clair sinon…
CodIMD est très frustre lui et supporte le core de MD et je trouve ça
notablement insuffisant.
Non CodiMD supporte GFM (github flavoured markdown) qui est donc une
extension (la plus connue, la plus utilisée au monde, donc ça va…).
Génial alors !
J’en ai rien à foutre que ce soit GFM ou autre, c’est plutôt limité et très tourné doc technique c’est tout ce que je dis.
Il y a des éléments de typo, en particulier française, qui ne sont pas natifs.
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.
À part les tableaux, je ne vois pas trop non plus. Je ne vois pas en
quoi SPIP aurait « plein » de choses en plus, c’est plutôt l’inverse.
Faudrait maintenir un tableau comparatif pour y voir plus clair sinon…
Oui mais c’est chiant.
Mais oui, il faudrait faire une comparaison sur plusieurs types de doc pas que de la doc technique.
Il y a des éléments de typo, en particulier française, qui ne sont pas
natifs.
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.
SPIP fait la deux, corrections typos + une syntaxe précise. Markdown
c'est juste une syntaxe.
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.
Mais c'est à part de la syntaxe et aucun rapport avec un standard
technique, ce sont juste deux fonctionnalités différentes.
Oui mais c'est chiant.
Mais oui, il faudrait faire une comparaison sur plusieurs types de doc
pas que de la doc technique.
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.
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.
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.
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.
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)
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
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)
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 ?
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 Basic Syntax | Markdown Guide
Parsedown-extra reconnait La syntaxe étendue de markdown
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: markdownlint demo
Perso je l'utilise sur vscode est c'est génial pour produire un code
markdown parfait
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 ?
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.
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 )
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 )
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.
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
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)
