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
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.
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
« 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
De quel volumes de code
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.
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é.
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 ?)
Ç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.
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 ?
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 !)
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…
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 Et je reproduis en effet ton souci avec l’inclusion des documents, mais je sèche sur le pourquoi du comment ^^
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.
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.
