Coloration Code et Coloration Live

Bonjour à tous,

Pour ceux qui n’auraient pas vu passer les commits, j’ai passé ces
derniers jours à travailler aux plugins Coloration Code (coloration
syntaxique d’extraits de code avec PrismJS) et Coloration Live
(coloration des raccourcis typographiques de SPIP dans les formulaires
d’édition).
Je risque d’avoir moins de temps prochainement donc si vous voulez
tester, amender, améliorer, etc., vos contributions sont les bienvenues
:slight_smile:

Par contre, je me demandais s’il ne pourrait pas être pertinent de
repenser l’architecture de l’ensemble en découpant en plusieurs petits
plugins - parce qu’en l’état, on a des librairies dupliquées, la
définition de la grammaire spip_typo en double, des tests pour vérifier
que l’on ne charge pas plusieurs fois PrismJS…

  • un plugin Coloration Code de base qui chargerait la librairie PrismJS
    et ses thèmes de base, dans le privé ou le public selon la
    configuration choisie par l’utilisateur (ce qu’on ne fait pas pour le
    moment) avec possibilité de définir un thème personnalisé pour le
    public et quelques plugins de PrismJS ;
  • un plugin Coloration SPIP qui ajouterait dans le formulaire de
    configuration du premier la possibilité d’activer les grammaires propre
    à SPIP (celle pour les squelettes, la seconde pour les raccourcis
    typographiques)
  • un plugin Coloration Live qui nécessiterait Coloration Code et
    Coloration SPIP et qui ne s’occuperait que de charger la librairie
    PrismLive et le thème adéquat pour les formulaires d’édition, avec
    choix d’activer sur le public potentiellement (si utilisation de
    Crayons – là, je ne garantis rien)
  • un plugin Coloration Code Extra Themes qui ajouterait au formulaire
    de conf de Coloration Code plusieurs ensembles de thèmes pour le
    public.

Qu’en pensez-vous ?

Merci :slight_smile:

1 J'aime

yo merci pour tout ce boulot :slight_smile:

là comme ça je vois pas du tout l’intérêt d’un découpage à outrance, juste deux plugins c’est largement suffisant, et je vois pas pourquoi il y aurait de la duplication :

  • coloration_code qui ajoute la lib JS + les deux syntaxes SPIP (puisque c’est un plugin pour SPIP) + des thèmes + un form de config pour l’activer privé et/ou public avec des thèmes possiblement différent dans les deux
  • coloration_live qui ajoute le live uniquement en se basant sur le premier qui fournit déjà tout le reste

En fait ma « théorie » était que

  • « coloration_live » (avec le minimum) pourrait être plus utile à de nombreux sites pour améliorer le confort d’écriture ;
  • tandis que coloration_code est déjà plus limité aux sites qui… montrent du code… Et qu’il inclut beaucoup plus de choses (thèmes, syntaxes diverses) et est donc un peu plus gros.

Et que potentiellement on pourrait fournir un jour coloration_live par défaut… (et que donc c’est mieux s’il est autonome).

Mais voilà c’était mon point de vue pour ce découpage.
Sinon, amha, il n’a pas lieu d’être : on l’inclut directement dans le plugin coloration_code qui alors gère tout.

Exactement. Soit on dit « les gens peuvent installer Live » sans tout ce qui est code, soit on force tout. Mais pas dire « pour avoir le live, il faut le code, mais à part »

Après en terme de decoupage on parle

  1. De quel volumes de code
  2. De combien d’assest chargés

C’est plutot cela qu’il faut se demander pour bien trancher.

@marcimat je suis plutôt d’accord pour dire que ça pourrait possiblement intégrer la dist oui

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.

Et donc « prism » pourra intégrer la dist si on veut un jour.

J’ai bien choisi « prism » et non pas un nom générique, car ya aucune assurance qu’un plugin coloration en live (comme peut le faire Codemirror) soit aussi pour l’affichage brut, et vice versa : c’est parfaitement propre à prism d’avoir les deux.

1 J'aime

J’en ai rêvé longtemps, et tu l’as fait. Merci.

Par contre, j’ai très rapidement (avec les enluminures typos activées) un décalage entre le vrai texte rendu invisible et le texte coloré. Ce qui rend impossible de positionner le curseur dans le bon texte.

Copie d’écran où le texte invisible est sélectionné et donc rendu visible au-dessus du texte coloré.

image

Merci à tous pour vos retours !

J’attends d’éventuelles autres contribution avant de me lancer dans les travaux de restructuration, sans doute pas avant la semaine prochaine de toute façon.

@RealET : pourrais-tu me transmettre le contenu de l’article en question via pastebin ? Je dois avouer que je n’utilise pas ce plugin. marcimat et rastapopoulos avaient déjà bien identifié le problème de changement de taille du texte - je ne sais pas si ce plugin joue là-dessus ; serait-ce dû à la police utilisée (sous quel OS et quel navigateur as-tu le problème ? quelle est la police retenue pour les éléments pre.prism-live et textarea.prism-live ?)

Merci encore et par avance.

Merci pour tout ça @bricebou

Ça donne envie d’avoir la partie live dans la dist oui.
Et dans ce cas là cette base devrait être la plus légère possible, donc juste ce qui rend possible la coloration live du code spip (et possiblement quelques compléments utiles ?).
Donc un découpage en 2 comme le propose rasta, ça à l’air pas mal.

Alors je n’ai pas encore testé la dernière mouture, mais après les vidéos des 1ères expérimentations de @marcimat, une remarque : pour le thème de la coloration de la syntaxe spip en live, je pense qu’il faudrait se limiter à quelques améliorations visuelles et ne pas forcément tout coloriser comme si on était dans un éditeur de code « normal ».
C.à.d mettre les hn à la bonne taille, du gras, de l’italique, etc. Et éventuellement indiquer discrètement les trucs ouvrants et fermants de la syntaxe Spip.
Sur le même modèle que dans certains éditeurs markdown, comme sur gitea par exemple.

Le texte : spip pastebin - outil de debug collaboratif - Bonjour les écureuils !
Le plugin : Enluminures typographiques V3 - SPIP-Contrib

Testé sous Windows 10 avec Chrome 90.
La police de

  • pre.prism-live : font-family: Consolas, Monaco, « Andale Mono », « Ubuntu Mono », monospace;
  • textareal.prism-live : font-family: Consolas, Monaco, « Andale Mono », « Ubuntu Mono », monospace;
  • Mais pour lt-mirror : font-family: LanguageTool-win, sans-serif !important;

Y a pas mal de choses à peaufiner encore dessus.

C’est quoi le lt-mirror : font-family: LanguageTool-win, sans-serif !important; ? C’est pas de prismjs ça ? C’est lui uniquement qui pose souci chez toi ?

Alors les titres on ne peut pas les grossir.

Prism-live se base sur une superposition d’un textearea (avec texte transparent) par dessus la coloration syntaxique. Si tu changes quelque part le line-height ou font-size de la coloration, tu te décales par rapport au texarea. De même si tu n’utilises pas une police monospace en mettant du gras (je suis déjà étonné que le gras seul ou l’italique seul ne pose aucun souci !)

Je ne sais pas, c’était visible rapidement dans la console quand j’ai inspecté le code :wink:

Sinon, 2 pistes pour que le gras ne prenne pas plus de place :

Merci, bonne idée pour le text-shadow. Pour la graisse, les polices qu’on a testé monospace finalement ne semblaient pas causer de souci. Tu en as toi juste avec le gras ou pas ?

Alors, même en virant le gras, j’ai ce problème de décalage… J’ai l’impression que ce sont les sauts de lignes qui posent problème, mais je ne vois pas comment résoudre ce souci…

Mais… mais… mais c’est top ! Merci :star_struck:

J’ai petit bug d’affichage :

  • créer un nouvel article
  • ajouter une image jointe
  • double-cliquer sur le raccourci dans la colonne de gauche pour insérer le code <doc1|center> dans le texte (ne pas faire de copier/coller)

Résultat chez moi : le code est bien inséré (et surligné) mais, si on clique ailleurs dans le champ texte (et donc on désélectionne le <doc1|center>), il disparait (problème de couleur ?) et ne réapparait que si on ajoute un nouveau caractère quelque part dans le champ texte.
Est-ce que vous reproduisez ?

Testé sur SPIP 4.0.0-alpha GIT master: [d9f4e39e] + saisies à jour + PHP 7.4.11 + Windows 10 + Firefox 88.0.1 et Chrome 90.0.4430.93

Aussi, j’ai l’impression qu’il manque un necessite saisies.

Bon, j’ai trouvé le problème de décalage : une déclaration font-size: 1rem pour les titres…

Sinon, @jeanmarie oui, il manque le nécessite Saisies, en effet, merci :slight_smile: Et je reproduis en effet ton souci avec l’inclusion des documents, mais je sèche sur le pourquoi du comment ^^

1 J'aime

Oui, j’ai pu voir sur les titres qu’ils étaient plus large dans la coloration.

D’où l’idée de pouvoir utiliser l’une des polices listées ici : https://uxdesign.cc/uniwidth-typefaces-for-interface-design-b6e8078dc0f7

Mais en soit, ça resterait fragile (si la webfont est pas chargée par exemple)

C’est un autre JS sur les documents qui gère cela, et du coup, il n’envoie pas d’événement ’Input’ au textarea après l’insertion je pense. Je suppose donc que ni markitup, ni prism-live n’est au courant de la modif du coup.

mais je sèche sur le pourquoi du comment ^^

Je connais pas le détail de comment c’est fait, mais @marcimat parlait d’un truc comme ça l’autre jour.

Intuitivement je dirais : prism live met à jour sa copie couleur quand ya des modifs dans le champs. Sauf qu’il ne détecte les modifs quand si « on tape » vraiment dedans. Avec les modifs claviers quoi.

Alors que là c’est une modif de l’exterieur, ya un JS de SPIP qui ajoute un contenu à l’intérieur du champ. Dans ce cas il faut arriver à le détecter et à forcer le recalcul de prism aussi.


RastaPopoulos

ils y a sans doute un trigger à declencher non ?