Comme évoqué sur IRC il y a quelques jours, je me suis amusé - c'est
vraiment le terme - à créer un plugin de coloration syntaxique
alternatif à Coloration Code, utilisant la librairie PrismJS.
Je n'étais pas très à l'aise avec Geshi et la surcharge des styles CSS
et puis je crois bien que ça ne couvrait pas mon besoin d'avoir un
prompt.
Bien évidemment, je souhaiterais pouvoir partager ce plugin si jamais
d'autres peuvent être intéressés. Par contre, il aurait bien besoin
d'être audité, puisque je ne suis aucunement développeur...
Vaut-il mieux que:
1. je le propose sur git.spip.net puis éventuellement sur plugins.spip.net ?
2. je l'héberge sur mon Github pour revue et seulement après revue il
intègre git.spip.net ?
Comme évoqué sur IRC il y a quelques jours, je me suis amusé - c'est
vraiment le terme - à créer un plugin de coloration syntaxique
alternatif à Coloration Code, utilisant la librairie PrismJS.
Et c'est une très bonne chose je pense (en tout cas de faire la coloration côté JS - quelque soit la librairie JS ensuite).
Je n'étais pas très à l'aise avec Geshi et la surcharge des styles CSS
et puis je crois bien que ça ne couvrait pas mon besoin d'avoir un
prompt.
C'est quelque chose à faire de basculer un jour "coloration_code" sur une lib JS plutôt que de faire le calcul en PHP. Je ne trouverais pas cela déconnant de faire une branche de dev-prismjs sur coloration_code pour tester PrismJs dessus, à la place de Geshi. C'est peut être un peu costaux à faire, mais quand ça marche, on le passe dans master. En acceptant de ne pas avoir la coloration "spip" au moins dans un premier temps, qui sera difficile à faire.
Bien évidemment sinon
- tu peux introduire ton propre plugin sur la zone (dans spip-contrib-extension),
- ou sur un espace qui te convient (github ou autre)
- ou forker sur la zone coloration_code sur ton compte le temps du dév si tu ne souhaites pas commiter directement sur une branche du plugin)
Ces 4 propositions sont correctes.
En général on préfère ne pas multiplier les plugins qui font la même chose (ici de la coloration syntaxique). Ma préférence serait donc l'adaptation du plugin coloration code, mais c'est peut être plus compliqué à faire.
+1 si tu te sens ok avec Git pour faire une branche de dev, ou trouver une personne pour te créer la branche s'il faut
En gros :
cd coloration_code
git checkout master
git branch dev/prismjs
git checkout dev/prismjs
=> tout casser dans cette branche
git push origin dev/prismjs
=> demander aux gens de tester
C'est comme cela que j'ai saisi l'ensemble des extraits de code jusqu'à
présent dans mes articles, ayant aussi ajouté des "boutons/raccourcis"
dans le Porte-Plume.
On a également besoin, pour faire un usage de certains plugins de
PrismJS des attributs data-* mais là encore on a un souci : https://core.spip.net/issues/4706
Du coup, je m'interroge pour commencer sur la bonne façon "spipienne"
de saisir des extraits de code...
Ne faudrait-il pas reconsidérer le code généré par <cadre> dans un
premier temps ?
Tout à fait, et quel serait le problème ? (et qui désactive javascript ?) La coloration syntaxique peut être considérée comme une amélioration progressive de la page. Ça n'empêche pas le site de fonctionner si tu ne l'as pas.
Le fait de basculer en JS plutôt qu'en PHP apporte plusieurs avantages :
- c'est plus simple à gérer côté SPIP : tu retournes le code tel quel ou presque
- si tu veux copier / coller le code source, tu n'as pas besoin de refaire un hit sur le serveur pour lui demander le code source brut (non coloré, qu'on a du mettre en cache spécial rien que pour ça : https://git.spip.net/spip-contrib-extensions/coloration_code/src/branch/master/coloration_code_fonctions.php#L105). Le code brut, c'est déjà ce que reçoit le navigateur par défaut : sans JS, au moins tu peux l'exploiter directement
- tu peux proposer l'édition du code directement dans le navigateur pour faire des tests lives, ce qui est impossible avec la coloration préalable côté PHP.
et merci de te pencher sur ce sujet, le plugin ColorationCode a bien rendu service mais il commence à dater un peu, enfin surtout Geshi.
Pour moi, ce vieux raccourci <cadre> devrait disparaitre, ne plus être proposé dans le porteplume, et pour assurer la compatibilité ascendante être systématiquement interprété comme le raccourci <code>, c'est à dire avec un <pre><code> en html, et pas cette verrue hideuse de textarea qui n'a rien à faire dans du html.
Historiquement, <cadre> génère un textarea "parce que c'est plus facile pour copier coller le texte", mais c'est vraiment un hack crado.
Pour moi, ce vieux raccourci <cadre> devrait disparaitre, ne plus être proposé dans le porteplume, et pour assurer la compatibilité ascendante être systématiquement interprété comme le raccourci
<code>, c'est à dire
avec un <pre><code> en html, et pas cette verrue hideuse de textarea qui n'a rien à faire dans du html
+1
Par ailleurs, Skeleditor fait déjà de la coloration de code à la volée (avec édition en live).
Donc, entre codemirror et PrismJS
Ça fait 2 libs js de coloration de code.
Je me suis mis à l'ouvrage et commence à avoir quelque chose de
fonctionnel, enfin, je pense... Mes quelques tests sur mes usages du
plugin me semblent satisfaisants.
Je vais me lancer dans la documentation de l'ensemble dans un thread
spécifique de la liste.
Cependant, serait-il possible d'avoir un accès sur git.spip.net pour
que je puisse verser ma branche de développement ?
Quand tu te cognes des sites complètement inaccessibles, y compris
institutionnels, et donc en France au moins dans l'illégalité, parce que
mal foutus et/ou bourrés de gadgets, la question qui se veut badine fait
grincer les dents.
En l'occurrence coloration code c'est relativement anecdotique et SPIP
est plutôt conscient de la question, mais d'une manière générale c'est
consternant d'avoir à rappeler qu'on devrait *toujours* pouvoir accéder
au *contenu* d'un site avec ou sans javascript, avec ou sans script à
interpréter côté client.
Voir en particulier la « note importante », page suivante.
Sans parler des problématiques de sécurité et de protection des données.
Justement comme l'a bien expliqué Mathieu : la coloration du code devrait en fait être juste une amélioration progressive en plus (de la déco), qui n'empêche pas du tout d'accéder au contenu lui-même quand il n'y a pas JS activé.
Par défaut sans JS, tu aurais le code, dans un balisage sémantique qui dit que c'est du code (<pre><code>). Et *si* tu as JS disponible : tu as de la déco de couleur en plus.
Ce serait donc même mieux qu'actuellement, à priori.
Mais supprimez cette page de git.spip, elle n'a aucun sens ! (surtout que la charte devenue officielle sur le site portail central était déjà en ligne bien avant l'utilisation de git.spip)
Mais supprimez cette page de git.spip, elle n'a aucun sens ! (surtout que la charte devenue officielle sur le site portail central était déjà en ligne bien avant l'utilisation de git.spip)
Tu sais utiliser git alors gogogo
Note : la page git est celle qui a été reprise depuis le trac/svn qui
date de bien bien avant et qui a toujours accompagné les mails
d'ouverture sur la zone. D'où le fait de sa présence sur les
communication git (vu qu'on a juste migré depuis le svn)
Donc le plus simple/propre/cool/... corrige le dépôt et on n'en parle
plus
