Test du plugin `coloration_syntaxique`

Dev
#1

Bonjour à tous,

J’avais commencé à développer un plugin de coloration syntaxique spécifique au DSFR.

Cette contribution étant limité aux utilisateurs du DSFR, j’ai décidé de fork et supprimer le code spécifique DSFR pour que tous les utilisateurs de SPIP puissent profiter du plugin !

Je vous présente donc mon nouveau plugin sobrement intitulé « Coloration Syntaxique » : spip-contrib-extensions / coloration_syntaxique · GitLab

Vous pouvez voir une démo live sur le site que je suis en train de faire ici : Portail SPIP - Le DSFR pour les SPIP de l'académie d'Orléans-Tours

Pourquoi ce nouveau plugin alors que les plugins coloration_code et prism permettent déjà d’ajouter un peu de couleur syntaxique ?

  • Et bien concernant coloration_code le plugin utilise la librairie highlightjs.org que je ne maitrise pas alors que j’avais déjà une experience avec PrismJS.
  • Quant à prism, le plugin est dédié uniquement à l’édition « live » des contenus SPIP et ne permet pas simplement de colorier un bloc de code.
  • La dernière raison étant que je débute sous SPIP, et j’ai encore trop peur de faire évoluer/modifier en profondeur un plugin déjà existant en risquant de casser la rétro-compatibilité.
    Bref, du coup, ça me paraissait plus simple de partir sur un plugin « neuf » pour avoir plus de liberté pour mon code sans être impacté par un héritage que je ne maitrise pas.

Je ne vais pas détailler ici comment fonctionne le plugin car vous pouvez retrouver toutes les informations sur le Gitlab : spip-contrib-extensions / coloration_syntaxique · GitLab

J’ai donc fini de coder les dernières grosses fonctionnalités du plugin et je pense prochainement le passer de dev en beta.

Avant cela j’aimerais avoir un retour de vos tests de ce plugin de coloration syntaxique si vous avez un peu de temps !

Merci beaucoup :wink:

#2

en jetant un coup d’oeil rapide sur ce qu’apporte ce plugin, je ne comprends pas trop la logique d’avoir créé un racourcis <dsfr-exemple_de_code> : pourquoi ne pas avoir utilisé un modèle html classique ? (cf la doc des modèles : Utiliser les modèles - SPIP)
…ce qui aurait permit également la simplification de son utilisation en ajoutant un fichier yaml « qui va bien » pour être utilisable avec le plugin Insérer modèles Plugin Insérer Modèles - SPIP-Contrib (et donc de bénéficier automagiquement d’un bouton dans la barre d’outils du porte-plume)

#3

autre question plus fondamentale sur ce plugin : pourquoi l’avoir préfixé « DSFR » et apposé l’avertissement sur les restrictions d’usages du DSFR sur son README.md : « Utilisation interdite en dehors des sites Internet de l’État » ?
Si je comprend bien, ce plugin n’est pas utilisable en dehors des sites de l’état ?
=> à priori, sur cette forge SPIP, il ne me semble pas pertinent d’héberger des plugins qui ne sont pas libres d’utilisation…

#4

Le 24/06/2024 à 16:30, JO via Discuter de SPIP a écrit :

La dernière raison étant que je débute sous SPIP, et j’ai encore trop peur de faire évoluer/modifier en profondeur un plugin déjà existant en risquant de casser la rétro-compatibilité.

Il faut pas avoir peur héhé : il y a des branches et des PR pour ça ! Donc tu peux rien casser, et tout le monde peut relire et tester avant de valider que c’est intégrable. En plus là c’eut été sur un plugin, pas sur le core, donc encore plus facile de faire des branches et PR. :slight_smile:

Pour ce qui est du plugin, j’ai l’impression que ça va être assez embêtant si on veut utiliser ça + prism pour l’édition, vu que ça va le fournir deux fois, et même sans conflit (si yavait du préfixage ou que sais-je) ça serait quand même deux fois pour rien, si on active les deux.

Donc ça serait quand même pas mal cool d’arriver à fusionner et qu’il n’y ait qu’un unique plugin qui fournisse la lib, et ensuite ça l’utilise pour de l’affichage (ta partie), et/ou pour de l’édition (ce qui existe déjà).

–
RastaPopoulos

#5

Il me semblait que l’édition avec Prism était juste une expérimentation, ça a vocation à devenir quelque chose d’officiel ?
En combinaison avec un nouvel éditeur wysiwym ?
Ça ferait une sacrée usine à gaz à maintenir…

#6

Je pense que le plugin auquel Jo fait référence est spip-contrib-extensions / coloration_syntaxique · GitLab
Qui est effectivement une « copie » en marque blanche de l’autre (DSFR)

1 « J'aime »
#7

Salut,

j’ai testé, sur un SPIP 4.2, ça marche pas mal du tout :slight_smile:
Avec les trois backticks+code du langage ```php, ou bien avec <code class="php">, ça fonctionne bien, l’affichage est propre.

L’exemple de code est pratique aussi, bien pensé :slight_smile:

Je vois que tu surcharges /plugins-dist/textwheel/wheels/spip/backticks.php pour pouvoir t’y insérer avec la coloration syntaxique, je pense qu’on devrait pouvoir trouver un mécanisme plus propre d’insertion (en ajoutant un pipeline dans textwheel ?)

Sinon, un tout petit bémol sur la couleur jaune de l’icone « code javascript » : ouille les yeux :smiley:
Mais c’est vraiment un détail infime par rapport au reste.

#8

Hello @cy_altern,

Alors attention tu as regardé l’ancien plugin DSFR. Justement j’ai fork et fais un nouveau plugin sans aucune référence au DSFR et sans aucune restriction d’utilisation (du coup j’ai supprimé le lien de mon message pour éviter la confusion).

Concernant le raccourci <exemple_de_code> un modèle classique ne fonctionnait pas car il faut pouvoir lui fournir des paramètres qui contiennent du code HTML ou SPIP. Par exemple, impossible de passer en paramètre un tableau SPIP (sous forme de raccourci avec plein de | et ||) à un modèle (inclut avec le raccourci de modèle SPIP).

Pour le bouton du raccourci <exemple_de_code> j’utilise justement la barre du porte plume (ainsi que pour les autres raccourcis de code)

#9

Merci,

C’est vrai qu’une pipeline dans textwheel éviterait du surcharger /plugins-dist/textwheel/wheels/spip/backticks.php.

J’ai eu besoin de cette surcharge pour rétablir le code encodé en base64, quand par exemple on ajoute du code entre backticks qui est lui même dans un raccourci <code>.

Du coup comme textwheel passe en premier dans les échappements on se retrouvait avec des bouts de code en base64 dans les codes colorié (le bug est présent dans spip core).

Par exemple sans le plugin coloration_syntaxique le code suivant affiche ce qu’il y a entre les backticks encodé en base64 (le plugin fixe ce bug grâce à la surcharge de textwheel)

<code class="spip">
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. 

```html
<div class="container">
	<div><p>Lorem Elsass ipsum bredele [...]</p></div>
	<div><p>Lorem Elsass ipsum bredele [...]</p></div>
	<div><p>Lorem Elsass ipsum bredele [...]</p></div>
</div>
```
</code>

Pour les couleurs, j’ai prévu un pipeline coloration_syntaxique_css pour ajouter ton propre fichier css et surcharger les couleurs. Par exemple pour le code JS, il faudrait dans ta feuille de style :

pre.spip_code.spip_code_block[data-language="javascript"],
pre.spip_code.spip_code_block[data-language="js"] {
	--coloration-syntaxique-couleur-illustrative-fond: red;
	--coloration-syntaxique-couleur-illustrative-texte: white;
}

Et hop, l’onglet et la couleur illustrative des blocs de code javascript sont en rouge avec le texte en blanc.

#10

A noter que j’ai également contourner la problématique des modèles avec 2 squelettes qu’on peut inclure ou on veut : inclure/coloration_syntaxique et inclure/exemple_de_code. Les raccourcis typographiques SPIP de code et <exemple_de_code> utilisent ces squelettes donc tout est unifié et normalement assez simple à maintenir.

#11

Pour ce qui est de coloration_syntaxique, la lib PrismJS et toutes les dépendances (css, grammaire, pipeline…) sont chargées uniquement lorsqu’il y a du code à colorier dans la page. Par contre j’ai testé avec le plugin prism en même temps et il y a bien un conflit car j’utilise la dernière version de PrismJS et ça à l’air de faire buguer le plugin prism (qui utilise une ancienne version de PrismJS pour le coup).

Pour le moment, je ne vois pas trop comment faire pour éviter ces conflits, en plus j’ai l’impression qu’il y a aussi un conflit sur les CSS.

#12

oups ! autant pour moi… mais ça mérite la précision pour éviter de se retrouver sur le « mauvais » plugin

effectivement pour passer des portions de code complètes le modèle n’est pas adapté

#13

Ah chouette ça :slight_smile:

Mais je parlais de l’icone « Code JS » dans le porte plume, en fonction de la couleur de l’interface ça peut piquer (chez moi c’est jaune sur un fond vert très clair)

EDIT : quelle que soit la couleur d’interface en fait, le jaune est pas vraiment visible.
Mais bon, ça c’est vraiment de la pétouille de finition.

Chouette boulot en tout cas !

#14

Oui c’est vrai je n’étais pas très inspiré pour les icônes. J’ai essayé plusieurs versions mais les icônes en 16px X 16px c’est très (trop?) petit. J’ai aussi essayé avec du texte dedans (genre CSS/HTML/JS) mais ça reste trop petit et illisible. Du coup j’ai mis le même icône uniquement avec la convention des couleurs pour chaque langage de programmation. Ensuite c’est assez simple de les surcharger par ses propres icônes si besoin !

En tout cas je suis preneur, si quelqu’un arrive à faire des icônes un peu plus parlant je peux les rajouter au projet :wink: