Mais le fait que ça soit ici « attr-value » c’est bien toi qui l’a définit quelque part non ?
Quelque part par là ? spip-contrib-extensions/prismlive - js/prism-spip-typo.js at master - prismlive - SPIP on GIT
Tu peux pas dire ici… bah c’est un alias url ?
C’est une mauvaise idée ?
Oui, on peut très bien lui donner un alias, ou faire en sorte que les URL soient considérées comme des .attr-value 
Tout se discute et il faut «juste» qu’on se mette d’accord sur ce que l’on souhaite collectivement ; mais nous n’avons pas tous la même idée de tout ça.
Comme je disais, une version « édulcorée », minimale de coloration via prism, + prism-live me paraissait une bonne idée. Il y a plus d’1Mo de fichiers de syntaxe dans Prism ; c’était pour ça que je trouvais mieux de limiter le nombre de syntaxe à ce qu’on est le plus possible amener à utiliser pour le Web & SPIP.
Cette solution là ne facilite ni la maintenance, ni le code, car il faut alors jongler avec deux plugins pour avoir toutes les syntaxes. C’est sûr.
Si on parle simplement de colorier en édition, alors la syntaxe SPIP et la syntaxe Markdown semblent logiques. SPIP ça va de soit forcément. Markdown c’est le de-facto substitut un peu partout pour l’édition, et nous avons un plugin qui peut un peu gérer les deux spip-contrib-extensions/markdown - markdown - SPIP on GIT
On avait aussi cette tentative d’avoir un éditeur Markdown (à base de https://ui.toast.com/tui-editor) à la place du Porte plume : Open Source / Porte Plume MD · GitLab mais je n’ai pas retesté depuis longtemps.
Et ne pas oublier que SPIP permet le HTML dans le texte :
<html> </html>
Donc, il faut aussi pouvoir colorer du HTML
@marcimat : il faut en effet décider si l’on fait :
@RealET je n’ai pas fait en sorte de parser tout ce qui n’est pas SPIP Typo comme du HTML, parce que je ne suis pas sûr que l’on gagne en lisibilité… Je vais l’ajouter, on verra
À la réflexion, si on doit faire en sorte que ce qui ne relève pas de la grammaire SPIP Typo soit parsé comme du HTML, ça oblige à charger un JS en plus… ça risque de faire beaucoup, à force, non ?
Bonjour à tous,
J’ai donc repris le plugin en l’appelant simplement Prism avec le dépôt désormais ici : https://git.spip.net/spip-contrib-extensions/prism
J’ai fait des modifications mineures des fichiers de la live PrismLive mais seulement sur des copies. Je ne sais pas quelle est l’approche privilégiée : laisser les fichiers d’origine ou pas ; dans le doute, ils sont dans le dépôt.
On charge la grammaire Markdown (et Markup, comme dépendance) si le plugin Markdown est actif et s’il est configuré pour que Markdown soit la grammaire par défaut.
Par contre, sur cette grammaire Markdown, j’ai été obligé de commenter le parsing des extraits de code, obtenant une erreur JS que je ne comprends pas (et je n’ai pas eu le temps de tester plus précisément).
Je n’ai pas encore ajusté la couleur des liens internes, par contre.
Ne me reste donc plus qu’à reprendre Coloration Code.
Merci par avance pour vos retours
Bonjour à tous,
Un petit message pour relancer d’éventuels retours que ce soit pour Prism ou pour Coloration Code.
Au sujet de ce dernier, certains avaient pu tester la branche proposant un nouveau raccourci ?
Quelles sont les prochaines étapes ? Je dois déjà produire une documentation qui tienne un minimum la route, mais à part ça ?
Merci encore et par avance !
Bonsoir à tous,
Après une longue période de pause dans mes bricolages spipiens, je reviens vers vous concernant ces deux plugins:
Comment procède-t-on pour releaser tout cela ?
Je fais une "demande d’ajout’ de ma branche vers master pour Coloration Code ? Et ensuite, qui se charge de taguer la nouvelle version pour apporter une mise à jour via SVP ?
Pour Prism, comment dois-je m’y prendre pour qu’il apparaisse dans SVP ? Et dans quel état ? dev, test… ?
Merci par avance ! et à bientôt
Concernant Prism, j’ai un comportement bizarre dans le chapeau de l’article avec le porte plume activé (via le plugin porte plume partout) : le div.prism-live n’est pas inséré au bon endroit dans le markup et passe donc sous la barre d’outil.
Avec le texte (invisible) sélectionné
Hum, merci @jeanmarie !
En fait, en fonction du navigateur, on a des comportements différents:
Pour régler ce souci, ma première idée est de :
Mais là je dois avouer que je ne sais trop comment faire pour ce dernier point… Des idées ?
Le 15/09/2021 à 13:17, Brice Boucard via Discuter de SPIP a écrit :
Mais là je dois avouer que je ne sais trop comment faire pour ce dernier point… Des idées ?
Pour PHP, il faut les plugins pour lesquels tu veux passer après
Pour JS, le plus carré c’est de lancer son propre truc dans un event JS « terminé/chargé » d’une autre lib, quand on veut être certain de passer après. Sinon vérifier si l’autre lib pose une classe CSS spécifique quand elle est bien finie d’être chargée, pour le détecter, ce genre.
Merci @rastapopoulos mais je dois avouer que cela reste assez obscur…
L’idée d"écouter un event JS avait été proposée si mes souvenirs sont bons dans d’anciennes discussions avec @marcimat mais ça nécessite de modifier le plugin Porte Plume Partout.
Je pensais conditionner mon pipeline à celui du PortePlumePartout avec un
if (test_plugin_actif('ppp') mais a-t-on moyen d’ordonner les pipelines de différents plugins ?
(en espérant être assez clair…)
Je pensais conditionner mon pipeline à celui du PortePlumePartout avec un
|if (test_plugin_actif(‹ ppp ›)| mais a-t-on moyen d’ordonner les pipelines de différents plugins ?(en espérant être assez clair…)
Mais je t’ai répondu déjà en tout premier mais j’ai oublié les ticks pour le code :
Pour PHP, il faut <utilise> les plugins pour lesquels tu veux passer après
Merci @rastapopoulos , j’avais oublié cet usage !
Par contre, même avec le <utilise nom="ppp" /> le problème subsiste sous Firefox… Plus énigmatique encore : si je désactive le cache dans l’onglet Réseau des Outils de développement, le problème disparaît… Mais même si je vide tous les caches (SPIP + Firefox), que je quitte et relance Firefox, le problème persiste…
Une idée ou mieux encore une solution ? ^^
Re à tous,
Bon, je crois avoir trouvé une solution à ce problème en spécifiant mieux la cible du script de chargement de prism-live (js/prism-live-spip.js.html) ; cf. On résoud le bug de décalage entre le textarea d'édition de SPIP et le pre de prism-live lorsque le plugin Porte Plume Partout est activé · cec6f46319 - prism - SPIP on GIT
@jeanmarie tu peux tester et me dire si le problème a bien été réglé de ton côté ?
Je suis preneur d’autres retours bien évidemment !
Merci à tous !
C’est bon avec ppp activé mais sans, il n’y a pas de coloration. Est-ce qu’on doit avoir la coloration même s’il n’y a pas les outils pour les raccourcis ?
Comme ça, je dirais bien oui parce qu’on peut les ajouter manuellement…
Le 16/09/2021 à 14:37, jeanmarie via Discuter de SPIP a écrit :
C’est bon avec ppp activé mais sans, il n’y a pas de coloration. Est-ce qu’on doit avoir la coloration même s’il n’y a pas les outils pour les raccourcis ?
Comme ça, je dirais bien oui parce qu’on peut les ajouter manuellement…
Mais c’est compliqué de discriminer : il devrait y avoir la coloration sur tous les champs qui vont passer dans propre(), mais comment le savoir ? Un textarea HTML n’est pas forcément toujours synonyme de syntaxe typo dedans.
Alors que quand on met la barre d’aide, c’est forcément qu’on est certain que le contenu va interpréter la syntaxe.
Je dirais que si un champ accepte la syntaxe (descriptif etc), il devrait toujours avoir la barre d’aide dessus dans ce cas, ne serait-ce qu’ergonomiquement ça indique aux utilisateurices que c’est ça qui est attendu dedans. Du coup ya un manque dans certains forms de SPIP aussi qui ne l’ajoute pas pour certains textarea qui pourtant permettent la syntaxe SPIP dedans.
Hum… Scrogneugneu… Le div .edition est en effet inséré lorsqu’une barre d’édition est présente…
Du coup, je ne sais pas comment résoudre ce problème en l’état… Et le pire c’est que je ne comprends pas la différence de comportement entre Chromium (Vivaldi ou autre) et Firefox, et même entre Firefox et Firefox avec le caché désactivé dans les outils de développement…
Si quelqu’un a une idée, forcément de génie, je suis preneur ! ^^
Mais, la discussion nous amène encore au-delà, et je dois avouer que je n’ai jamais trop compris pourquoi on n’avait pas de barre d’édition pour les champs descriptif, chapo, etc. par défaut…
Et du coup, une idée : si on ajoutait une classe genre .editer_propre sur tous les champs concernés ? ça pourrait permettre à Prism de cibler sans se tromper et super facilement (enfin je pense).
Mais du coup… que fait-on ? qui fait quoi ?
Bonsoir à tous,
Je relance histoire de voir peut-être un jour ces deux plugins releasés ^^
Merci par avance pour vos retours, propositions, solutions, corrections…
