Gestion des extraits de code : coexistence de Pre&Code, Prism et ColorationCode

Dev
#1

Bonsoir à tous,

Je me suis réattelé au plugin Prism et à la résolution d’issues restées quelque peu en souffrance… Parmi elles, celle-ci : « Conflit avec le plugin precode » (https://git.spip.net/spip-contrib-extensions/prism/issues/9)

C’est tout simple : le plugin Pre&Code prend les classes associées à une balise <pre>et les affiche dans un pseudo élément :before de la balise <code> ; et ce quel que soit le contexte, j’ai bien l’impression, que ce soit dans une visualisation d’article dans le privé ou le public, ou bien au sein même d’un textarea lors de l’édition d’un article. Et qui plus est, le plugin fournit des styles CSS sur des sélecteur extrêmement générique (pre code, par exemple).

Du coup, je profite de l’occasion pour initier une discussion quant à la façon de présenter du code dans SPIP… J’avais travaillé il y a maintenant plusieurs mois à une branche de Coloration Code (https://git.spip.net/spip-contrib-extensions/coloration_code/src/branch/dev/prismjs) qui bascule de l’utilisation de Geshi côté serveur à la librairie javascript PrismJS (https://prismjs.com/) qui nécessite de son côté un balisage à base de classe au format language-XXX.

Sur une autre branche de Coloration Code j’avais aussi travaillé à la création d’un raccourci typo du genre <c|grammaire> : https://git.spip.net/spip-contrib-extensions/coloration_code/commit/a70ea173181cef6ffbf978106cb5a7b6636ef35d
Alors, ça date de quelques mois, le code est peut-être pas très propre en l’état…

Du coup, est-ce que l’on ne proposerait pas une refonte des plugins ayant trait au code ? Du genre :

  • Code - Structure => gestion de la structure : raccourci SPIP, formatage HTML en <pre class="language-XXX"
  • Code - Coloration => gestion de l’affichage : coloration des différents langages pris en charge par Prism auxquels on peut ajouter la syntaxe SPIP + prise en charge d’un certain nombre de plugins (numéro de lignes, toolbar avec affichage du langage, copier…)

Ou alors un seul et même plugin avec configuration avancée ?

Reste alors la question de la gestion de la dépendance à la librairie PrismJS aussi nécessaire dans PrismLive…

Alors, désolé si ça rejoint voire rejoue une partie d’une discussion vieille de près de deux ans, mais ce serait chouette de pouvoir présenter une gestion unifiée des extraits de code.

Merci par avance pour vos retours !

#2

Je ne sais pas pour SPIP 4.1, mais…

Si tu pars sur une compat SPIP 4.2+, il me semble que pre-code est tout ou partie fusionné dedans, et du coup ça doit résoudre une partie des soucis. Surtout qu’on a encore éventuellement le temps d’adapter SPIP 4.2 s’il y a des mini-corrections à y faire de ce côté.

Spip 4.2 prend en compte les raccourcis de code en markdown, notamment triple backtick+nom de langage (mais ne fait pas de coloration du code). Du coup, à lire ton commentaire, je ne vois pas l’intérêt du plugin « structure ».

Je suis 100% favorable par contre évidemment à passer du vieux Geshi à Prism dans coloration code (ou tout autre plugin nouveau si besoin pour le remplacer). Et si c’est juste en version stable pour SPIP 4.2+ c’est pas déconnant je pense.

Pour prism-live, je trouve l’idée absolument géniale (coloration de la syntaxe SPIP lors de l’écriture des articles dans le back-office), mais à chaque fois mes tests sur des articles longs, on sentait une latence d’écriture pas très agréable (je n’ai pas retesté récemment cela dit) ; qui plus est, la lib ne semble pas maintenue.

#3

Salut @marcimat, merci beaucoup pour ce retour !

Je viens donc de tester et c’est juste génial cette nouveauté de la 4.2 ! et du markup que j’ai regardé rapidement, aucune difficulté particulière pour brancher un PrismJS dessus pour la coloration syntaxique, la numérotation des lignes, la toolbar permettant de copier le code.
La question qui se pose donc : comment procéder vis-à-vis de Coloration Code ? on cherche une rétrocompatibilité ou est-ce que je ne produirai pas directement un nouveau plugin compatible 4.2+? Qui peut-être utiliserait plutôt highlight.js (GitHub - highlightjs/highlight.js: JavaScript syntax highlighter with language auto-detection and zero dependencies.) qui semble plus actif et plus maintenu ?

Pour ce qui est de la coloration live, cela mérite effectivement une réflexion plus large sans doute surtout au vu de sa non activité…
Basculer sur un CodeMirror ou autre Monaco editor (les deux sont sous une licence MIT) comme suggéré à une époque par @RealET ?

#4

Tant mieux si le markup est correct sur 4.2 !

La question qui se pose donc : comment procéder vis-à-vis de Coloration Code ? on cherche une rétrocompatibilité ou est-ce que je ne produirai pas directement un nouveau plugin compatible 4.2+?

Mon avis serait de faire une branche de coloration code qui casse la compat ascendante, et simplement compatible SPIP 4.2+, histoire de ne pas démultiplier les plugins. Il est pour moi illusoire de maintenir la compat’ avec Geshi, et donc amha, ça va dans ce sens. Ceci étant dit, sens toi libre aussi si tu préfères faire un plugin de remplacement (et abandonner donc ce nom « coloration code », déprécier le plugin et sa doc, pour un autre totalement différent).

Je n’ai pas d’avis entre prismjs et highlight par ailleurs. Encore une fois, je n’ai pas regardé depuis un moment ces choses là.

#5

highlight.js c’est un excellent outil. Je les avais testés les deux en cherchant un outil qui ne casse pas CSP
https://w3c.github.io/webappsec-csp/#strict-dynamic-usage

Il s’avère que prism faisait tout exploser (je crois que c’étaient les injections inline) tandis que highlight fonctionnait parfaitement parce que travaillait au niveau du CSSOM. De mémoire

prism

style="••••••"

highlight
document.getElementById(id).setAttribute('style', '••••••');

#6

Comment procéder dans ce cas où il convient donc de tout casser d’une certaine façon ? Je créée une nouvelle branche en --orphan, jesupprime tout dedans et je fais comme si je débutais un nouveau plugin ?

git checkout --orphan branchname
git rm -rf .

@lspeciale : je vais essayer de regarder plus précisément HighlightJS du coup, mais j’ai du mal à saisir de mes premières lectures s’il peut fonctionner en mode lazy loading comme PrismJS (c’est-à-dire n’aller chercher que les JS nécessaires aux seules syntaxes présentes sur la page).

#7

Pistes

#8

Bonsoir,

Du coup, voici où j’en suis :

  • je suis parti de l’existant Coloration Code
  • j’ai créé une nouvelle branche en mode orphan :
$ git checkout --orphan dev/42-highlightjs
$ git rm -rf .

Je suis donc reparti d’une page blanche avec la librairie highlight.js ; je propose deux modes d’utilisation :

  • une méthode statique où l’on sélectionne les grammaires que l’on souhaite sur toutes les pages, de manière classique, à travers le pipeline insert_head
  • une méthode « à la volée » qui load via javascript les grammaires présentes sur la page, avec l’inconvénient de peut-être se planter avec les CSP et de ne pas bénéficier des mécanismes de concaténation et de cache de SPIP.
    J’ai essayé de faire un laïus à ce sujet dans les explications des champs de configuration et dans la description du plugin ; j’espère ne pas trop m’être planté !

Et j’arrive au moment où je souhaiterais pouvoir vous présenter ce travail ! mais avant de pousser la branche ainsi créée, j’aimerais avoir votre aval, histoire d’être sûr de ne pas mettre trop le bordel.

Merci encore et par avance

1 « J'aime »