[spip-dev] Un autre éditeur de texte est possible : feuille de route

Je synthétise là toutes mes recherches du jour.

Cahier des charges :
- Dans l'éditeur lui-même, avoir une vue plus sémantique de ce que l'on tape (WYSIWY Mean !)
- Pouvoir mettre en plein écran
- Pouvoir prévisualiser le vrai rendu HTML final (avec les images, modèles, etc)
- Pouvoir éditer côte à côte avec la prévisu
- Être pérenne et que le noyau puisse reconnaitre plusieurs syntaxes

Des gens ont fait ça pour Markdown mais malheureusement QUE pour Markdown. Mais en fait quasiment tout ce qui est important est géré en sous-main par CodeMirror !
https://simplemde.com/

Leur éditeur est en fait relativement simple :
=> c'est CodeMirror à 80%
+ ils ajoutent une CSS qui ne change pas juste la couleur pour la syntaxe, mais aussi la taille, pour les titres, gras, italique, etc
+ ils ajoutent une barre de boutons
+ ils ajoutent un système de prévisu (seul ou côte à côte)

CodeMirror est entre l'autre l'éditeur de code de Chrome et Firefox, et de milles autres choses. Il est à priori (très) pérenne, modulaire, et sait gérer plusieurs syntaxes en les déclarant dans un module JS (un "mode"). En plus de la reconnaissance de syntaxe, il gère déjà plein de plugins comme raccourcis claviers, continuer une liste quand on fait Entrée, etc.

Pour SPIP je propose cela :
- faire un mode CodeMirror qui gère uniquement les modèles SPIP, et peut-être les liens (ce qui permettrait de l'utiliser avec d'autres syntaxes que SPIP, notamment dans Markdown)
- faire un mode CodeMirror pour tous les trucs SPIP autre que modèles
- faire une CSS qui rend plus sémantique la saisie SPIP (agrandir les intertitres, etc)
- récupérer la CSS pour la saisie Markdown de SimpleMDE
- trouver une barre de boutons se basant déjà sur CodeMirror : les boutons ne feraient qu'appeler des comportements CodeMirror
- re-implémenter notre système de prévisu + de fullscreen et côte à côte dans cette nouvelle barre (= comme SimpleMDE !), sachant que nous la prévisu ça appelle un truc serveur, alors que SimpleMDE il semble que c'est tout en JS client.

Je pense que le plus gros est de faire les deux modes de syntaxes SPIP pour CodeMirror. Mais une personne a fait un projet très cool qui apparemment fonctionne déjà : une déclaration de grammaire en JSON, beaucoup mieux que la programmation JS des modes de CodeMirror :
https://github.com/foo123/codemirror-grammar
Et ça marche !

Pour le reste, on doit pouvoir s'inspirer de SimpleMDE mais en généralisant :
1) Ce serait bien d'avoir une barre de bouton pour SPIP *et* pour Markdown en même temps (en fait avoir deux déclarations, suivant le mode voulu)
2) Avoir notre prévisu-serveur.

Comme on le remarque, je propose deux choses qui permettent de garder Markdown sous la main :
1) séparer la déclaration des modèles (et peut-être des liens)
2) avoir deux déclarations de boutons

Cela permettra d'office, avec le même éditeur, la même base commune, de savoir gérer à la fois SPIP et Markdown. Cela me semble important à prendre en compte dès le début.

Je vais peut-être garder tout ça dans un ticket…

Voilà :
https://core.spip.net/issues/3720

J'ai demandé s'il existait un exemple de description de grammaire pour une syntaxe légère (parce que ses exemples fournis sont tous pour de la programmation) :
https://github.com/foo123/codemirror-grammar/issues/5

La démo de SimpleMDE est assez sympa et une telle présentation serait un gros progrès pour le confort des utilisateurs en leur permettant un aperçu en temps réel de ce qu’ils font. Merci pour cette proposition d’émalioration de l’éditeur de texte qui reste le principal point de difficulté pour aborder SPIP en tant que contributeur éditorial. On demeure cependant éloigné des attentes des utilisateurs car on reste dans une syntaxe ad hoc qu’il faut apprendre ou au moins comprendre pour commencer à rédiger sur SPIP. Même si les boutons aident ça désoriente. La logique ne devrait-elle pas être inversée avec une vue WYSIWYG par défaut, où on peut intervenir, et un éditeur avancé en syntaxe SPIP pour les utilisateurs qui veulent vérifier / affiner leur saisie ? Les raisons qui avaient conduit à écarter initialement ce type d’interface sont-elles encore valables aujourd’hui ? Même en montrant le rendu à droite de l’écran on introduit de la complexité là où le rédacteur devrait se concentrer sur son contenu.

Bonne journée,

Valéry-Xavier

Pour ce point je le précise explicitement quand même : cette barre DOIT être accessible.

La logique ne devrait-elle pas être inversée avec une vue WYSIWYG par
défaut, où on peut intervenir, et un éditeur avancé en syntaxe SPIP pour
les utilisateurs qui veulent vérifier / affiner leur saisie ? Les
raisons qui avaient conduit à écarter initialement ce type d'interface
sont-elles encore valables aujourd'hui ?

http://romy.tetue.net/wysiwyg-wysiwym-wysiwyc

Oui, même aujourd'hui, c'est TRÈS compliqué à faire correctement. Wikipedia avec des ANNÉES de codage et un GROS budget argent, ils ont fini par réussi à en faire un, mais QUE pour eux, pour leur syntaxe perso (ce qui est dommage, vu le budget, de pas avoir fait un système plus générique…).

La plus grosse difficulté c'est que l'aperçu en temps réel ne doit pas générer du HTML, mais doit générer le langage final, y compris pour les modèles (la syntaxe wikimedia a le même système que nous pour ce point, ils ont des modèles avec des paramètres aussi). Pour cela l'éditeur de Wikimedia passe par un arbre JSON abstrait de ce qu'on est en train d'éditer. Puis ensuite ça l'enregistre en base dans leur format wiki. Leur éditeur est vraiment très très complexe, beaucoup (vraiment !) plus que les éditeurs WYSIWYG classiques qui ne font que générer du HTML basique.

Ce n'est pas totalement impossible, mais donc oui, c'est *énormément plus compliqué* que de faire un éditeur WYSIWY MEAN, qui ne met en forme que la sémantique générale (titraille, gras, etc).

Même en montrant le rendu à droite de l'écran on introduit de la complexité là où le rédacteur devrait se concentrer sur son contenu.

Les rédacs doivent se concentrer sur le sens de leur texte surtout, pas sur leur aspect visuel. Mais justement les éditeurs WYSIWYMean permettent ça, en mettant en avant la hiérarchie des titres, etc.

Le fait d'avoir un "retour direct", qui va par exemple agrandir le texte dès qu'on met {{{un truc comme ça}}} autour, ça permet aussi d'apprendre plus rapidement le langage de balisage léger (quel qu'il soit, SPIP ou Markdown).

Et ce type de langage, une fois connu, est BEAUCOUP plus rapide à rédiger que de cliquer sur les boutons en permanence (les boutons c'est bien justement quand on débute, pour aider, mais ensuite c'est plus efficace de taper direct les raccourcis).

Avec MD, si je veux faire un titre de niveau 2, je peux taper rapidement :
## Mon titre

Avec du WYSIWYG uniquement, je dois taper "Mon titre", puis enlever les mains du clavier (arrêter ma saisie donc), prendre la souris, sélectionner le texte, et cliquer sur un bouton voire une liste déroulante. => beaucoup moins efficace au quotidien.
(Ce qui n'empêche pas d'avoir des boutons avec la syntaxe légère en même temps, pour aider les débutants justement.)

Cf cette expérience là aussi, très parlante de ce point de vue :
http://romy.tetue.net/barre-outils-edition-raccourcis

Bonjour,

les raccourcis clavier me semblent encore plus rapides que les codes typographiques (et pas besoin de lâcher le clavier !)

Il y en a dans l’éditeur standard de Spip d’ailleurs.
Cmd/Ctrl B = Mise en gras, etc.

Perso je suis pour un Wysiwyg qui produit du code Spip, comme ça on a le meilleur des deux mondes !

Amaury

les raccourcis clavier me semblent encore plus rapides que les codes
typographiques (et pas besoin de lâcher le clavier !)

C'est faux : c'est totalement impossible d'avoir des raccourcis claviers pour l'ensemble des instructions possibles. Tu peux juste en avoir pour 3 ou 4 trucs maximum, les plus courants, gras, etc.

Perso je suis pour un Wysiwyg qui produit du code Spip, comme ça on a le
meilleur des deux mondes !

Donc non, vu que tu pourras juste avoir des raccourcis pour 4 trucs, et tout le reste il faudra bien pouvoir les générer quand même, et en accessible à tou⋅te⋅s (cf le dernier lien).

Mais bon, si quelqu'un a le budget de la Fondation Wikimedia (25 millions de dollars), et quelques années devant, allez y hein, go go go ! :smiley:

Valéry-Xavier Lentz a écrit le 28/02/2016 08:02 :

La démo de SimpleMDE est assez sympa et une telle présentation serait un
gros progrès pour le confort des utilisateurs en leur permettant un
aperçu en temps réel de ce qu'ils font.

C'est déjà le cas avec le nouveau bouton de la barre d'outil en SPIP 3.1
Testable ici : http://syntaxe.spip.net/

Merci pour cette proposition
d'amalioration de l'éditeur de texte qui reste le principal point de
difficulté pour aborder SPIP en tant que contributeur éditorial. On
demeure cependant éloigné des attentes des utilisateurs car on reste
dans une syntaxe ad hoc qu'il faut apprendre ou au moins comprendre pour
commencer à rédiger sur SPIP. Même si les boutons aident ça désoriente.
La logique ne devrait-elle pas être inversée avec une vue WYSIWYG par
défaut, où on peut intervenir, et un éditeur avancé en syntaxe SPIP pour
les utilisateurs qui veulent vérifier / affiner leur saisie ? Les
raisons qui avaient conduit à écarter initialement ce type d'interface
sont-elles encore valables aujourd'hui ? Même en montrant le rendu à
droite de l'écran on introduit de la complexité là où le rédacteur
devrait se concentrer sur son contenu.

CkEditor a, si j'ai bien compris, la possibilité de générer directement n'importe quelle syntaxe, et pas seulement du HTML.
Et ça, dans les 2 sens (WYSIWYG <-> syntaxe)

Ils l'ont codé pour BBcode :
- CKEditor Documentation Website
- Démo : BBCode Editing | CKEditor 4 Documentation : clic sur source, rajouter dans le source dui gras, revenir en WYSIWYG, le gras est bien là !

La même chose pour BBCode :
http://hectorguo.com/CKEditor-Markdown-Plugin/

Est-ce le Graal que tu cherchais Rastapopoulos ?

RealET a écrit le 28/02/2016 22:07 :

La même chose pour BBCode :

Il fallait lire : pour Markdown

:wink:

Bonsoir,
ce n'est pas tout a fait dans ce que tu proposes RastaPopoulos,
mais voici un autre outil

http://wiki.txt2tags.org/demos/txt2tagsjs/txt2tagsjs-gui.html