Coloration Code et Coloration Live

Alors, là, j’avoue que je ne serais pas contre un coup de main ^^

Sinon, j’ai repris l’intégralité de Coloration Live dans un plugin prismlive ; que vaut-il mieux que je fasse : supprimer le dépôt Coloration Live existant et créer un nouveau dépôt ou renommer le dépôt existant et faire un commit (sans doute assez moche) ?

Merci encore et à bientôt !

supprimer le dépôt Coloration Live existant et créer un nouveau dépôt ou renommer le dépôt existant et faire un commit (sans doute assez moche) ?

Garder l’historique c’est forcément mieux (mean obligatoire). Mais ça peut se faire aussi en supprimant le dépôt (tant que t’as toujours l’historique en local et que tu le pousses). De toute façon faut pas repartir de zéro donc même en local là faut faire un commit qui change le préfixe etc.


RastaPopoulos

Hum… Je suis reparti de zéro en fait, en reprenant seulement les morceaux pertinents…
Si je supprime tout le contenu de mon dossier coloration_live et que j’y copie l’ensemble des nouveaux fichiers, ça le fait quand même ?

Y a encore beaucoup de boulot sur la grammaire des raccourcis typo de SPIP (je constate beaucoup de soucis encore…)
Du coup, quelle approche préféreriez-vous ? Quelque chose de « minimaliste » comme proposé par tcharlss ou quelque chose de plus complet ?

Si je supprime tout le contenu de mon dossier coloration_live et que j’y copie l’ensemble des nouveaux fichiers, ça le fait quand même ?

bé l’idée c’était de garder l’historique git, mais là si tu pars d’un truc vide et que tu recopies juste quelques fichiers, yora plus… tant pis

Y a encore beaucoup de boulot sur la grammaire des raccourcis typo de SPIP (je constate beaucoup de soucis encore…)
Du coup, quelle approche préféreriez-vous ? Quelque chose de « minimaliste » comme proposé par tcharlss ou quelque chose de plus complet ?

Qui peut le plus peut le moins :slight_smile:

Moi je trouve plutôt bien que le max soit pris en compte par la syntaxe, après tout est une question de quels styles on y met ensuite, mais c’est très bien que ce soit reconnu. Et yen a pas tant que ça, donc justement quand ya un lien ou un modèle il faut que ça saute aux yeux pour moi, pas juste titre et gras.

De même les blockquote en gris un peu plus clair aussi et/ou italique (pas que les balises mais tout le texte entre), ce genre de choses.

Faut déclarer le max de ce qu’on arrive à faire reconnaitre à la grammaire à mon avis, et après on voit ce qu’on style et comment.


RastaPopoulos

Ok, merci @rastapopoulos ! J’y ai été moins à la serpe, je suis reparti de coloration_live et ai renommé et modifié les fichiers, ça fait un commit un peu plus propre… J’en ai profité pour renommer le dépôt, désormais : spip-contrib-extensions/prismlive - prismlive - SPIP on GIT

Pour la grammaire SPIP Typo, je vais par contre repartir d’une page vierge et implémenter les choses vraiment petit à petit… mais ça va se faire vraiment au ralenti dans les prochains jours.

Merci encore :slight_smile:

Bonjour à tous,

J’ai repris la grammaire SPIP Typo que je crois avoir améliorée par rapport aux précédentes versions ; on peut sans doute faire mieux encore… N’hésitez pas à tester et à regarder de plus près aux regex ^^

Pour rappel, le plugin est désormais appelé prismlive et son dépôt est là: spip-contrib-extensions/prismlive - prismlive - SPIP on GIT

Je vais m’attaquer désormais à la réécriture de Coloration Code !

Bonne journée

Bonjour,

Je viens de tester la version du jour.
Super pour les décalages qui sont complètement réglés, merci !

Par contre, en édition d’un article en cliquant sur le plein écran qui affiche le résultat sur la droite, impossible de scroller le texte de prévisualisation à droite.

Merci d’avance :wink:

Bonjour à tous,

J’ai donc apporté quelques modifications et à prismlive (notamment le problème signalé par @RealET – même si je suis pas certain de la propreté du CSS en résultant) et à coloration_code, notamment pour ce qui est de la cohérence avec prismlive, des contrastes du thèmes par défaut (même si la palette de couleurs peut être revue bien évidemment) et surtout une réécriture de la grammaire pour SPIP.

Au plaisir de lire vos retours de test !

Bonne soirée, bon week-end :slight_smile:

1 « J'aime »

Je viens de tester rapidement et chapeau ! :cowboy_hat_face:
Tu as corrigé quasiment tout (et en plus le fullscreen fonctionne).

Il faut que je teste sur des grands contenus pour vérifier tout cela.

Quelques points :

  • Il faut peut être que tu attendes parfois quelques retours de plus avant de tout changer ce que tu codes :slight_smile: Là par exemple je trouve un poil dommage d’avoir renommé en « Prism live » qui n’est pas hyper causant au premier abord (à moins de savoir ce qu’est la librairie Prism à la base). C’est pas du tout un drame non plus. Au moins c’est au nom de la lib JS derrière.
  • Je reste très sceptique sur l’utilisation de la balise <lib> (surtout si on met le plugin un jour dans la distribution en tant que plugin-dist). Pour presque preuve, j’ai du supprimer lib/prismjs que j’avais du précédent plugin pour que ça re-télécharge la bonne version (au bon endroit surtout - avant c’était dans un sous dossier 1.23 et plus maintenant). Malheureusement SPIP et SVP gèrent très mal cette partie là d’autant plus si le zip change de structure. Ça sera très différent une fois qu’on utilisera Composer cela dit. (un jour ! un jour !)
  • Pour la même raison (de mettre dans la distribution), la dépendance à Saisies sera peut être embêtante. Mais au delà de ça, si la vocation du plugin est de juste colorier la syntaxe SPIP, peut être qu’il n’est pas utile de fournir une configuration de couleurs de thème ? A priori, fixer les variables CSS utilisées me semble suffisant pour ce plugin et la coloration d’édition SPIP ?
  • J’adorerais si possible que le plugin puisse colorier l’aide en ligne aussi dans la foulée, de la même façon (a priori il devrait pouvoir). Peut être qu’on peut mettre une classe spécifique pour cette coloration (pour éviter que ça ne perturbe le plugin coloration code par exemple), ou trouver quelque chose, un truc, un compromis pour le faire :slight_smile:

Sinon j’ai envoyé une correction pour que l’ajout de documents actualise bien la coloration, en nettoyant le fichier spip_barre.js. Ça fait partie des vieilleries : ça causait même de hotjava, mort en 1999 !

Suppression de code JS non utilisé · 3e9c27572b - spip - SPIP on GIT
Une fonction beaucoup plus à jour pour ajouter du contenu à un textarea · 42f598ae13 - spip - SPIP on GIT
Si barre_inserer() est appelé sans préciser d'élément, bien vérifier que l'élément possède une fonction de sélection de texte. · 39ab940502 - spip - SPIP on GIT

Donc la nouvelle fonction envoie un événement Input (comme ceux que j’ai ajouté au porte plume).

Par contre dommage là dessus : comme on utilise le « double clic » pour ajouter le texte des modèles, on ne peut pas utiliser le document.activeElement, car ça déselectionne le textarea et activeElement n’est plus pointé sur lui : j’avais espéré secrètement que ça pourrait insérer dans le textarea qu’on est en train d’éditer… mais j’ai pas réussi du coup. Ou alors faut trouver autre chose que double clic (des boutons peut être ?)

Je viens de le faire :

  1. Ça marche !
  2. C’est hyper fluide !

Aparté : je pense

  • qu’il faut colorier les URLs comme les liens internes (en bleu)
  • qu’il ne faut pas de couleur de fond (du moins la même que celle prévue habituellement en édition sans le plugin)

Bonjour,

Merci beaucoup pour ce retour et ces évolutions :slight_smile:

  1. en effet, j’ai un peu foncé… mais pour ce qui est du nommage du plugin, voir plus loin…
  2. en fait, vu qu’elle est mutualisée, je me disais que c’était ce qu’il y avait de plus propre, et je n’ai pas reproduit ce qui générait une mauvaise vérification de la présence de la lib comme précédemment (mauvaise idée que de faire télécharger la lib sous prismjs/1.23.0 parce que SVP doit se contenter de vérifier les répertoires directement dans lib/)
    Mais ça pose en effet la question de la mise à jour de la lib…
    La solution serait donc plutôt d’intégrer la librairie PrismJS dans le premier (mettons pour le moment PrismLive) et que Coloration Code aille la chercher dans _DIR_PLUGIN_PRISMLIVE ? Mais est-ce que c’est très propre ?
  3. Pour la configuration, oui, peut-être peut-on s’en passer (en mode grosse flemme de se taper le formulaire à la mano…)
  4. Pour ce qui est de l’aide en ligne, logiquement ce devrait pouvoir la colorier avec class=« language-spip_typo » sur tous les pre qui présente des extraits de la syntaxe, non ? PrismJS est chargé, la grammaire est chargée… Je ne comprends pas…
    Mais pour rebondir sur le 1, j’imagine que l’on pourrait donc revoir la structure des deux plugins : un plugin Coloration SPIP qui chargerait seulement dans l’espace privé PrismJS ainsi que les grammaires SPIP et SPIP Typo, et un plugin Coloration Code qui chargerait et dans le privé et sur le public les autres grammaires, les plugins et qui permettrait lui de choisir un thème.
  5. pour ce qui est de colorier les liens, c’est un poil plus complexe : on peut identifier clairement une URL (de type http(s)://… mais beaucoup moins les liens internes, ce qui fait que dans un cas, on a un token url, et dans l’autre un token attr-value… On peut modifier le CSS pour que ces deux token ait le même style, mais je suppose qu’il y avait une raison pour qu’ils ne le soient pas dans le thème par défaut… Après, je peux sans doute créer une regex pour identifier tous les cas genre /(art(icle)?|rub(rique)?|mot)[0-9]+/ et leur attribuer le token URL. Mais il me faudrait lister l’ensemble des objets possibles et inimaginables…
  6. Oui, pour la couleur de fond, sans souci !

Merci encore !
(et je vais attendre quelques retours avant de me lancer)

Précisions là dessus : les « liens internes » sont déjà coloriés en bleu dans [truc->muche] donc pour moi ça c’est bon et je trouvais cela bien. Et du coup j’espérais les URLs de la même manière. S’il y a un token url directement c’est bon non ?

Sur ça, ça fonctionne effectivement sur l’url http://dev.spip.test/ecrire/?exec=aide&aide=raccourcis directement mais pas en ajax dans la modale.

C’est pas embêtant que prismjs se lance tout seul dans ce plugin sur tous les pre/code.language_x (qui n’a pas de syntaxe de coloration du coup autre que celle de spip ?)

@marcimat clairement ce double clic n’est pas une bonne idée, et n’est même pas accessible : ça devrait être des boutons dès qu’il y a interaction ! (Et en plus de l’interaction, même juste en terme d’ergonomie, la majorité des gens ne comprennent pas qu’il faut double cliquer ou ne s’en souviennent jamais, car ça ne correspond à RIEN dans le web : les liens on clique une fois, les boutons on clique une fois)

Béééé moi non plus je n’ai pas compris ton nommage @bricebou vu que ça c’est exactement ce que j’avais conseillé plus haut…

Mais dans ce cas je verrais :

  • un plugin « prism » qui fournit toutes les libs JS une seule fois + la syntaxe spip + et qui active le live SPIP dans l’admin (possiblement par défaut, est-ce qu’il y a une raison de rendre ça configurable ?)
  • un plugin coloration_code qui nécessite prism et qui ajoute des thèmes, et de la configuration pour activer prism en affichage sur les contenus, en privé et public. Et du coup ce plugin n’aurait plus les libs.

Dans l’optique que ça puisse intégrer le core, l’idée c’était bien un plugin « Prism » tout court, qui fournit directement toutes les libs : la lib centrale + le live, directement en JS dedans, mais qui au niveau de l’insertion de fonctionnalité n’ajoute que la syntaxe SPIP + l’activation du live dans le core (possiblement désactivable mais même pas sûr ou par define). Et ensuite Coloration Code nécessite ce plugin Prism mais n’a rien à fournir en lib, juste en thèmes + notre syntaxe de template + une page de config pour choisir thèmes privé et public

En fait c’est là qu’on n’est peut être pas en phase. J’imaginais un prism «minimal» : ie: sans langages autres que (spip | php | html | css | json | js | md — les trucs possiblement utilisés pour/dans SPIP), et sans thèmes.

Mais de ce que je comprends, dire «la lib centrale», ça inclut alors tous les différents langages et quelques thèmes (c’est fournit avec la lib justement par défaut), et donc c’est déjà un peu plus gros que ce que je pensais à la base. Et la différence avec «coloration_code» serait alors assez réduite (juste la conf et des thèmes en plus… hum ?)

Ah non moi j’avais plus en tête la lib javascript, les 2 ou 3 fichiers JS (prism.js + prismlive.js quoi), et donc seulement avec la syntaxe légère SPIP (peut-être 1 ou 2 autres mais pas plus).

Et dans coloration code, toutes les syntaxes du monde, des thèmes, de la config.

J’avoue que si ça doit être dans le Core je suis plutôt de l’avis de Matthieu. Une coloration qui supporte les langages minimaux de SPIP.

Hum… Je crois qu’il convient de reposer un peu les choses: à l’origine on a le plugin Coloration Code qui se charge de coloriser les extraits de code entre <pre><code class="language-xxx">...</code></pre> sur la partie publique (et dans le privé). Ensuite, on a Coloration Live / PrismLive qui lui se charge de coloriser les raccourcis typographiques de SPIP lorsque l’on édite un contenu dans l’espace privé.

La logique voudrait que Coloration Code soit une dépendance de Coloration Live / PrismLive mais je comprends l’idée de faire l’inverse si on vise une intégration dans les plugins-dist. Je comprends maintenant pourquoi passer par la balise <lib> du paquet.xml est donc une mauvaise idée…

Ce qu’il est possible de faire avec PrismJS c’est de ne pas passer par le plugin Autoloader (qui se charge de détecter les grammaires utilisées dans la page et de les charger à la volée) – ce que fait Coloration Code actuellement – et de charger par défaut autant de grammaire que l’on souhaite, mais ça fait autant de JS en plus au chargement de la page… D’ailleurs, je ne vois pas pourquoi l’on aurait besoin d’autre chose que la grammaire SPIP Typo dans l’espace privé pour ce qui est de l’édition. Si l’on veut prévisualiser joliment les extraits de code, on installe Coloration Code…

Donc, dans un premier temps, on renomme PrismLive pour que ce soit plus parlant, éventuellement même « agnostique » – non dépendant de la librairie utilisée – soit en Coloration Live soit en Édition colorée, je ne sais pas, vous me dites.

Coloration Code charge la librairie PrismJS sur la partie publique, avec le thème et les plugins souhaités, ajoute des boutons au Porte Plume… ce qu’il fait déjà.

Le problème reste donc entier pour l’ex-PrismLive : inclure la librairie PrismJS intégralement ou non ? Je dois avouer qu’en termes de maintenance, il me semble que ce serait beaucoup plus simple et lisible.

En fait, il faudrait des cas d’usage où l’on aurait besoin des grammaires PHP, Markdown…

Ce que je disais c’est que l’on a deux cas de figure:

  • avec [test->art42], art42 est parsé comme la valeur d’un attribut (token .attr-value)
  • avec [test->https://example.com], l’adresse est parsé comme une URL (token .url)

Or le token .attr-value a les même styles que les token .atrule et .keyword, tandis que le token .url a ceux des token .operator, .entity…
Et je crains des effets indésirables en stylant de la même façon les .url avec les .attr-value…

D’où plutôt ma proposition de détecter les art42 comme des URL ; mais la question, c’est quels sont les objets qui peuvent être liés de la sorte ? Je suppose que la liste est loin d’être finie ? Ou alors, on passe par une option ? Genre un define(‹ COLORATION_LIENS_INTERNES ›) avec un array d’objets (art, article, rub, rubrique, mot, par défaut) ?

Non… tous les objets même ceux que tu ne connais pas encore peuvent marcher ->{objet}{id}

Il me semble que tu peux changer les regroupements dans le CSS ? Notamment décorréler .token.url de ses copains ?

 .token.operator,
 .token.entity,
 .token.url,
 .language-css .token.string,
 .style .token.string {
   color: var(--prismlive-color-url);
   /* This background color was intended by the author of this theme. */
   /* background: hsla(0, 0%, 100%, .5); */
 }

=>

 .token.url {
     color: var(--prismlive-color-url); // à mettre bleu
}
 .token.operator,
 .token.entity,
 .language-css .token.string,
 .style .token.string {
   color: var(--prismlive-color-string); // à définir
 }

Mais là c’est des styles un peu généraux si je pige bien, pour toutes les syntaxes. Ce qui me semble plus important c’est de styler spécifiquement pour le langage spip_typo peut être ? ou en tout cas spécifiquement les éléments .prism-live …

Ce que je veux dire c’est qu’il y a 2 choses du coup qui vont arriver. Le plugin (prism ou prism-live comme il sera nommé) :

  1. va gérer la coloration de <pre><code> (prim) de certains formats (particulièrement spip_typo) dans la vue des articles, dans l’aide en ligne. Il y a là dessus
    a. Le style général du cadre de code, qui doit ressembler à … un bloc de code (et sur lequel on peut appliquer éventuellement des thèmes différents dans l’espace public avec le plugin coloration-code)
    b. Le style issu du type de coloration syntaxique (le nom des tokens mis sur les éléments)
  2. va gérér la coloration «en édition» (prim-live) de certains formats (particulièrement spip_typo, et peut être uniquement lui ; l’autre candidat serait markdown). Là dessus
    a. Le style général doit être le plus proche de la décoration habituelle du textarea dans l’espace privé (avec ou sans le porte plume)
    b. Le style issu du type de coloration syntaxique s’applique aussi.

En édition au moins, dans le cas de la syntaxe spip_typo, c’est très bien de connaitre tous les tokens différents, mais ce n’est pas obligatoire de tout colorier avec trop de couleurs différentes. Il me semble (et tu l’as très bien fait en général) que voir les accolades, les crochets des liens, le | des tableaux, l’opérateur → des liens est assez important, de même que colorier les liens dans la couleur habituelle (bleu ou la couleur utilisateur --spip-color-theme-dark ?), mais il ne faut pas que ça devienne un arbre de noel non plus : l’important me semble de faciliter la perception de ce qu’on écrit, sans en faire trop. Il ne faut pas détourner le rédacteur ou la rédactrice de son écriture. On ne cherche pas à écrire du code informatique ici :slight_smile:

Il faut trouver le bon compromis dans tout cela :slight_smile: