ZEP-14 : Refonte de l'assistant d'édition Markdown

Je pourrais intégrer rapidement les raccourcis, ça se fait super rapidement en js MAIS il faut se mettre d'accord sur quels raccourcis, on définit.

Les trois contraintes sont :

• Facilement devinable.
• Pas en conflit avec les navigateurs principaux: firefox, chrome, ie, opéra, lynx … .
• Pas en conflit avec les printipaux os et environnement de bureau.

Merci.

Ici plus besoin d'attendre le GSOC qui n'aura pas lieu. Du coup si un dev' front veut se faire plaisir il peut

Du coup on avance comment ? On résume ou on en est ? Chacun continue a proposer ses petites demandes et on harmonise ? Florian tu es toujours la pour mettre a jour l'OP ?

Perso si on se met a proposer, voici quelques idées :

• une popup s'affiche si on veut fermer l'onglet ou changer de page alors qu'on a du contenu dans la boite de texte (se serait con de perdre du contenu avec une fausse manip') ;
• Une sauvegarde auto se fait toutes les xx secondes en LocalStorage au cas d'un crash du navigo/pc ;
• Avoir des raccourcis clavier de rédaction (gras, italique, lien…) ;
• Agrandir la hauteur par défaut, on se sent tout serré la !!

Rien que c'est quelques trucs c'est déjà pas mal pour moi

Ensuite un peu plus tard :

• Avoir un upload d'image plus performant (drag'n drop + fallback sur un input file classique serait le must) -> attente de l'API des galeries
• Avoir un aperçu en live (cf l’idée/implémentation de Javier)

J'aime la plupart de tes idées, mais par pitié pas la popup qui empêche la fermeture de page…

mais par pitié pas la popup qui empêche la fermeture de page…

Ah ouai oO ? Ça t'es jamais arrive de perdre du contenu par inadvertance ? Perso oui et c'est frustrant (je parle bien de son affichage QUE si un contenu est deja commence a taper dans la zone de texte (limite même mettre un seuil de déclenchement en nombre de caractères pour éviter de s'afficher pour les tout petits textes)

Ça m'arrive pas souvent et ça fait un moment que ça m'est pas arrivé, mais si je me souviens bien, sur mon navigateur la plupart du temps quand je fais ça et que je rouvre l'onglet fermé, la textarea contient ce que j'étais en train de taper.

Un backup auto en localStorage ou autre truc du genre, pourquoi pas, mais je n’apprécierai vraiment pas une popup.

Vaut mieux une sauvegarde en local storage oui.

Tant pis pour les gens en navigation privée.

(NB : bien penser côté client à checker la possibilité d'accès au localStorage et pas laisser crasher, et du coup : afficher un message propre en disant à la personne : c'est dommage pour toi tu manques des features en étant en mode incognito, mais on respecte ton choix ça marche quand même).

Florian tu es toujours la pour mettre a jour l'OP ?

Yep, j'essaye de faire ça aujourd'hui ou au plus tard demain.

J'aimerais bien me faire plaisir là-dessus (y'a vraiment des trucs sympas à faire) mais j'ai pas le temps…

Il y a une synthèse de cette ZEP ?

Ou tout est présent sur le premier post ?

Mise à jour de la ZEP faites ! Dites-moi ce que vous en pensez. Le gros nouveau point, c'est l'aperçu en temps réelle.

Pour les images, j'ai mis un bloc question, car j'ai cru apercevoir dans la conversation qu'on attendrait l'API des forums avant de faire quelque chose de ce côté !

Ça me paraît un peu lourd ce temps réel. Mais pourquoi pas, si certains membres veulent l'option…

Je serais plus pour un aperçu manuel par défaut (parce qu'après tout, on ne regarde pas le résultat à chaque lettre entrée) et le temps réel pour ceux qui l'activent.

Personnellement, je suis de ton avis.

Mais je l'ai tout de même mis, vu que s'est apparu dans la conversation et, au-moins les nouveaux verront qu'on a discuté et qu'ils peuvent donc aussi en débattre ! Puis, cette ZEP est encore en rédaction, donc à voir avec la suite si ça restera ou non !

L'apercu temps reel c'etait surtout "Si on a le temps et les ressources serveurs pour le faire", mais en soit c'est pas une obligation dans cette ZEP.

Et en soit ca devrait attendre que le markdown soit mappé en API, non ?

Y'a de grandes chances, surtout pour le temps réel qui demande des WebSockets (donc un dév. spécifique)…

Mais même pour l'aperçu manuel il faudra bien un WebService qui fasse ça de façon plus légère que de faire un appel Ajax vers une page de prévisualisation avec le template complet du site.

C'était un peu (aussi) pour ça Kje que je demandais si la nouvelle version de zmarkdown était embarquable sur n'importe quelle machine.

Ca peut être un projet complètement différent du site lui-même. Et ça me paraît même plus sain en fait.

Ca falloir un serveur "haute-performance" qui sait gérer beaucoup de websockets à la fois, beaucoup de "requêtes" de prévisu sans avoir besoin d'autre dépendance que zmarkdown. (pas besoin de l'intégralité modèle du site par exemple). Et pour ce genre de trucs ça me paraît plus sain et perenne de pas bundler tous les services sur un seul et même serveur applicatif.

Là j'ai utilisé un petit serveur Java pour la démo, mais j'imagine que y'a tout un tas de solutions pour faire ça en Python avec un serveur "bas niveau" (pas besoin de MVC et tout le tralala).

Oui il y a des trucs en python mais techniquement pour la partie "extrait -> html" c'est Pandoc qui s'en chargera, donc un executable, donc manipulable depuis n'importe quel langage en fait. Je suis assez d'accord avec Javier. A terme il faudrait qu'il y ai un projet a part pour faire les conversions mardown -> HTML au niveau extrait.

A noter un petit bug de front lié à cette ZEP, https://zestedesavoir.com/forums/sujet/2969/choix-de-coloration-syntaxique/?page=1#p53419

Par ailleurs, je ne sais pas si ça a déjà été débattu, mais j'ai récemment eu besoin de couleur dans un de mes tutos. Constatant qu'il n'était pas possible de le faire, j'ai dû réécrire le paragraphe pour expliquer en texte ce qui est évident avec la couleur.

Le débat sur la couleur revient souvent, et la réponse est toujours du genre « Les couleurs, quand c'est mal utilisé, ça mène à n'importe quoi, donc on l'empêche pour rester cohérent ». C'est plus une ligne directive qu'une vraie réponse, mais c'est celle qui a été adoptée ici

Après, on peut toujours en débattre.

Dans ton cas, qu'est ce que ça donne si tu utilise de l'italique, ou bien du gras ? (qui se verra mieux, à mon avis)

Dans ton cas, qu'est ce que ça donne si tu utilise de l'italique, ou bien du gras ? (qui se verra mieux, à mon avis)

Ça donne des erreurs 500

Plus sérieusement, je ne sais pas si ça se voit bien sur l'image, mais le gras et l'italique sont déjà exploités, la couleur est là pour accentuer le contraste, car le simple gras n'y suffit pas, surtout sur de la ponctuation.

[ liste de capture ]( paramètres ) mutable -> type de retour { contenu }

^{à noter que j'ai dû rajouter des espaces visibles entre les éléments en gras et les éléments en italique, parce que sinon il fait n'importe quoi}

« Les couleurs, quand c'est mal utilisé, ça mène à n'importe quoi, donc on l'empêche pour rester cohérent »

J'avoue, de par mon langage de prédilection qu'est le C++, ne pas adhérer du tout à cette philosophie .