Je n’ai pas eu le temps / l’occasion de regarder, et je ne pense pas pouvoir avant un petit moment encore, j’en suis bien désolé car tout ça m’intéresse !
Juste un petit mot d’encouragement car, après un rapide test, je trouve que c’est en effet un ajout qui aurait vraiment du sens dans le core. Ca pourrait être une aide précieuse pour que les rédacteurs s’y retrouvent avec la syntaxe de balisage (ou voient leurs erreurs).
Et sans y aller par quatre chemins : ça en jette ! 
En attendant de faire un retour plus constructif dès que j’aurais le temps : pareil que @Mathieu_L , des encouragements ! L’édition est bien plus agréable avec ça → objectif core
Merci pour les encouragements !
Alors, je viens d’essayer de changer d’approche (via le commit On essaie une nouvelle approche... Mais sous Firefox, le premier chargement du form d'édition présente toujours un décalage, résolu dès que l'on recharge la page (Ctrl+r) · 54dc903cbd - prism - SPIP on GIT) et le code produit n’est sans doute pas des plus propres…
Par contre, il y a du mieux : on peut avoir la coloration syntaxique sur tous les textarea du form d’édition d’article, que l’on ait activé ou pas le Porte Plume Partout.
Le seul souci, c’est encore sous Firefox que ça se passe : pour que le pre de prism-live et le textarea soient bien superposés, il faut recharger la page après le chargement initial du formulaire…
J’attends vos retours pour confirmer ce comportement
Le problème ne viendrait-il pas des fois justement de Porte Plume Partout (j’ai l’impression que le code obtenu sur chacun des .editer n’est pas le même que celui du champ #TEXTE) ?
J’en profite pour avoir d’autres retours par rapport à la proposition de @rastapopoulos.
Est-ce que ça ne devrait pas faire l’objet d’un ticket pour le core (si c’est bien là que ça se passe) ?
Est-ce que ça ne devrait pas faire l’objet d’un ticket pour le core (si c’est bien là que ça se passe) ?
Pour ce point en particulier, sisi c’est bien sûr dans le core qu’il faut l’indiquer, si on pense que c’est un problème ergonomique de ne pas signaler explicitement chaque champ qui accepte la syntaxe.
Comme ça fait un certain temps que je vois passer ce thread, je me décide finalement à l’ouvrir espérant que ça puisse aider. Les colorateurs je me les suis farci tous avec une config CSP avec Apache TRES stricte et le seul qui fonctionnait (je le repète avec un config de protection hyper stricte au niveau du JS et surtout des injections HTML) était HighlightJS. Les autres se prennaient CSP dans les gencives.
On Tue, Sep 21, 2021 at 9:48 PM Brice Boucard via Discuter de SPIP <noreply@discuter.spip.net> wrote:
Brice Boucard bricebou
Septembre 21Merci pour les encouragements !
Alors, je viens d’essayer de changer d’approche (via le commit On essaie une nouvelle approche… Mais sous Firefox, le premier chargement du form d’édition présente toujours un décalage, résolu dès que l’on recharge la page (Ctrl+r) · 54dc903cbd - prism - SPIP on GIT) et le code produit n’est sans doute pas des plus propres…
Par contre, il y a du mieux : on peut avoir la coloration syntaxique sur tous les textarea du form d’édition d’article, que l’on ait activé ou pas le Porte Plume Partout.
Le seul souci, c’est encore sous Firefox que ça se passe : pour que le pre de prism-live et le textarea soient bien superposés, il faut recharger la page après le chargement initial du formulaire…J’attends vos retours pour confirmer ce comportement
Le problème ne viendrait-il pas des fois justement de Porte Plume Partout (j’ai l’impression que le code obtenu sur chacun des .editer n’est pas le même que celui du champ #TEXTE) ?
J’en profite pour avoir d’autres retours par rapport à la proposition de @rastapopoulos.
rastapopoulos:
Je dirais que si un champ accepte la syntaxe (descriptif etc), il devrait toujours avoir la barre d’aide dessus dans ce cas, ne serait-ce qu’ergonomiquement ça indique aux utilisateurices que c’est ça qui est attendu dedans. Du coup ya un manque dans certains forms de SPIP aussi qui ne l’ajoute pas pour certains textarea qui pourtant permettent la syntaxe SPIP dedans.
Est-ce que ça ne devrait pas faire l’objet d’un ticket pour le core (si c’est bien là que ça se passe) ?
Voir le sujet ou répondre à ce courriel pour répondre.
En réponse à
RastaPopoulos
Septembre 16Le 16/09/2021 à 14:37, jeanmarie via Discuter de SPIP a écrit : C’est bon avec ppp activé mais sans, il n’y a pas de coloration. Est-ce qu’on doit avoir la coloration même s’il n’y a pas les outils pour les raccourcis ? Comme ça, je dirais bien oui parce qu’on peut les ajouter manuellement… Mai…
Réponses précédentes
tcharlss
Septembre 21En attendant de faire un retour plus constructif dès que j’aurais le temps : pareil que @Mathieu_L , des encouragements ! L’édition est bien plus agréable avec ça → objectif core
MathieuAlphamosa Mathieu_L
Septembre 21Juste un petit mot d’encouragement car, après un rapide test, je trouve que c’est en effet un ajout qui aurait vraiment du sens dans le core. Ca pourrait être une aide précieuse pour que les rédacteurs s’y retrouvent avec la syntaxe de balisage (ou voient leurs erreurs).
Et sans y aller par quatre chemins : ça en jette !
Matthieu Marcillaud marcimat
Septembre 20Je n’ai pas eu le temps / l’occasion de regarder, et je ne pense pas pouvoir avant un petit moment encore, j’en suis bien désolé car tout ça m’intéresse !
Brice Boucard bricebou
Septembre 20Bonsoir à tous,
Je relance histoire de voir peut-être un jour ces deux plugins releasés ^^
Merci par avance pour vos retours, propositions, solutions, corrections…
Brice Boucard bricebou
Septembre 16Hum… Scrogneugneu… Le div .edition est en effet inséré lorsqu’une barre d’édition est présente…
Du coup, je ne sais pas comment résoudre ce problème en l’état… Et le pire c’est que je ne comprends pas la différence de comportement entre Chromium (Vivaldi ou autre) et Firefox, et même entre Firefox et Firefox avec le caché désactivé dans les outils de développement…
Si quelqu’un a une idée, forcément de génie, je suis preneur ! ^^Mais, la discussion nous amène encore au-delà, et je dois avouer que je n’ai jamais trop compris pourquoi on n’avait pas de barre d’édition pour les champs descriptif, chapo, etc. par défaut…
Et du coup, une idée : si on ajoutait une classe genre .editer_propre sur tous les champs concernés ? ça pourrait permettre à Prism de cibler sans se tromper et super facilement (enfin je pense).Mais du coup… que fait-on ? qui fait quoi ?
Voir le sujet ou répondre à ce courriel pour répondre.
Pour se désabonner de ces courriels, cliquez ici.
Je viens de faire un rapide test avec Firefox pour voir si je pouvais aider à débugger mais je n’ai pas le problème signalé 
@lspeciale serait-ce possible d’avoir de plus amples informations ? des retours sur ce que renvoie le plugin Prism voire des pistes d’amélioration ?
@Mathieu_L tu veux dire que tu as la coloration parfaitement superposée au textarea sur l’ensemble des champs (descriptif, chapo, ps) en plus du champ Texte ? Que ce soit avec ou sans le plugin Porte Plume Partout ?
@bricebou Oui, j’ai fait un test sur le chapo et ça fonctionnait. Je n’ai pas le plugin PPP. Fais moi signe si tu veux que je fasse plus de tests.
Pour moi également aucun problème de superposition sur firefox, cf. capture.
Par contre un truc bizarre : la navigation au clavier est très lente, le curseur met bien longtemps à se déplacer d’une lettre à l’autre. Mais pas dans tous les cas, ça ne me fait ça que dans les textarea sans porte-plume.
Merci @Mathieu_L et @tcharlss !
J’ai fait une modif ce matin du JS qui appelle Prism Live, qui le déclenche sur les textarea, avec un setTimeout qui permet (si je comprends bien les dysfonctionnements) d’attendre que le plugin Porte Plume Partout (lorsqu’il est activé) ait bien fini de charger les barres d’outils.
On peut sans doute mieux faire…
@tcharlss plus particulièrement : je n’ai à aucun moment rencontré ce problème :-/ j’utilise Firefox sur une Debian 11 à jour. Et toi ?
Je vais essayer de le tester sur un site de test en ligne pour y accéder depuis différentes machines et plateformes…
On verra les éventuels retours de @jeanmarie qui a déjà pas mal éprouvé le plugin, et d’autres volontaires bien sûr
Je suis sur Ubuntu 21.04 / Firefox 92, et je teste avec Spip 4.1-dev sur un formulaire d’article (dépôts coloration et prism à jour de ce matin).
J’essaierai d’activer le porte-plume sur les autres textareas pour voir si le lag est bien lié à son absence ou pas.
Ça me parait bizarre de lancer la coloration sur les champs qui n’ont pas le porte-plume (càd sans indication explicite qu’on peut utiliser la syntaxe). C’est pas à ce plugin de décider à mon avis, le contrôle sur où devrait se faire en un unique endroit, d’une unique manière. Donc si boutons alors coloration, uniquement. Que les boutons soient ajoutés par le core ou un plugin qui en rajoute, peu importe.
@tcharlss je viens d’essayer sur une version de Firefox plus récente (88.0.1) depuis les dépôts de Debian unstable mais je ne reproduis pas plus que sur ma version de Firefox-ESR (78.14).
@rastapopoulos oui, ça semble plus cohérent ; mais rien de trop difficile : il suffit de cibler la classe .edition (ajoutée par le porte plume) plutôt que .editer et le tour est joué (du moins après un test rapide chez moi).
Est-ce plugin est compatible 3.2 ? Actuellement, la borne mini est 3.3 dev.
Et j’en profite pour me joindre aux encouragements, c’est vraiment un bel outil pour l’expérience utilsateur·rice
@jeanmarie Pour la compatibilité, je ne vois pas trop pourquoi il ne le serait pas… Au début de mes bricolages, je n’avais qu’une version de dev sous la main donc je n’ai pas testé avec des versions <= à 3.2. Tu as moyen de tester facilement ?
En SPIP 3.2 il y a 2 problèmes :
- la coloration se fait bien mais après une frappe au clavier : j’écris un mot, je le sélectionne, je clique sur le bouton pour le mettre en gras, les accolades sont bien ajoutées mais sont invisibles et, lorsque je tape à nouveau au clavier, les accolades apparaissent colorisées
- le textarea est de la même couleur que le fond (cf 2 captures ci-dessous)
avant
après
Arf… Bon, on va le laisser compatible seulement avec les versions >= 4.0 alors.
Non ?
1 « J'aime »
Je pense que ce sera plus simple 4.0+ oui (voire 4.1+ si on doit faire des adaptations spécifiques dans le core).
Ceci étant dit, c’est du à un événement js que j’ai ajouté dans le PP pour que ça marche (https://git.spip.net/spip/porte_plume/commit/03d554632f97 : ça serait ça à reporter dans la branche 3.2 du PP sinon : mais bon, on considère qu’elle est plutôt en security-fix (voire petits bugfix) et qu’on n’y fait pas d’amélioration, donc…)
1 « J'aime »
Juste un retour rapide : j’ai installé Prism sur 2 sites que je viens de livrer et les retours utilisatrices sont super bons, un vrai gain UX pour les personnes qui rédigent