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

Tentons de l'améliorer au besoin des membres !

a marqué ce sujet comme résolu.

Alors, je vais essayer de répondre à tout ça

Pour ce qui est du rendu côté client, faut bien se dire que c'est juste un highlight de la syntaxe du Markdown, pas un rendu complet. C'est pas du tout dans l'objectif de remplacer la preview, c'est juste complémentaire. Du coup, le seul risque, c'est que dans certains edge-case chelou, on aura éventuellement une coloration syntaxique pas de la bonne couleur. Je suis vraiment pas sûr que c'est très gênant. A ce niveau la, je pense que ça fait même un meilleur boulot que l'éditeur actuel. Vous avez déjà essayé de mettre en gras sur plusieurs lignes ? Sur l'éditeur actuel, ça va wrapper toute la sélection par des **, alors que c'est censé le faire séparément sur chaque ligne. Je pense que ce genre de comportements bizarre risque plus d'induire les utilisateurs en erreur que quelques edge-case sur de la coloration syntaxique. :-°


Je spawn ici juste pour dire que le seul truc qui m'embête c'est le fait que ça pèse quand même plus de 110kb […]

C'est 64Kb actuellement minifié + gzippé.

Alors, faut savoir que mon code est relativement peu dépendant de CodeMirror, surtout au niveau de la logique de l'éditeur. Je songe actuellement à faire une sorte d'interface avec lequel l'éditeur va communiquer, qui permettrait de plugger l'éditeur soit sur CodeMirror s'il est chargé et qu'on est sur Desktop, soit sur un textarea standard, s'il est pas chargé et/ou on est sur mobile, et charger les 60Kb de CodeMirror en asynchrone.


Si maintenant, vous me dites clairement "osef de la coloration syntaxique du markdown", dans ce cas OK, je peux tout à fait complètement virer CodeMirror. Je trouve ça juste très dommage, et ça empêchera le développement de features avancé type rechercher/remplacer, voir même l'autocomplétion en plein milieu de l'éditeur (enfin encore que, GitHub le fait bien, mais d'une manière assez dégueulasse :-° ). Aussi, je trouve que la coloration syntaxique permet presque de se passer de preview en temps réel ; et étant donné que le peu d'avancement sur l'amélioration du rendu markdown depuis pas mal de temps, je pense que c'est mieux comme ça :)

+2 -0

Encore une fois je ne dis pas qu'il ne faut pas le faire mais que c'est un risque. C'est pour ça que je conseil de le faire sur les inlines seuls pour le moment et quand ce sera dispo voir pour les blocs (qui seront plus complexes à géré et plus sujet aux problèmes).

Après c'est qu'un conseil…


edit:

petit exemple sans aller loin :

1
***toto*truc*mush***

la seule interprétation qui suppose que le code est correct de ça serait <strong><em>toto</em>truc<em>mush</em></strong>.

Ton éditeur semble l'interpréter correctement, python-zmarkdown lui se plante :

tototruc*mush*

Ma remarque est juste que là tu va avoir des incompréhensions des utilisateurs

+0 -0

petit exemple sans aller loin :

1
***toto*truc*mush***

la seule interprétation qui suppose que le code est correct de ça serait <strong><em>toto</em>truc<em>mush</em></strong>.

Ton éditeur semble l'interpréter correctement, python-zmarkdown lui se plante :

tototruc*mush*

Ma remarque est juste que là tu va avoir des incompréhensions des utilisateurs

Kje

… et Pandoc génère <p><strong><em>toto</em>truc<em>mush</em></strong></p>. C'est vraiment la peine de se priver de ce genre de features pour des edge-case chelou que de toutes façons fonctionnent différemment sur le site même, en fonction de si on est dans un PDF ou sur le site directement ?

+0 -0

Bah Pandoc fait comme ton éditeur, c'est normal et cohérent. C'est zmarkdown qui se plante.

Après pour la 3eme fois moi je suis POUR qu'on pousse ton éditeur mais qu'on le fasse par etape en ajoutant le support des éléments de langage au fur et à mesure pour vérifier que ça ne perturbe pas trop les utilisateurs.

Bonjour à tous,

vu de l'extérieur, voilà ce que je vois :

  • on a une v16 qui est en attente car on n'a pas de testeur pour faire la QA des PR qui corrigent les bugs découverts
  • on a une v17 qui est en attente car on sait pas si on doit utiliser django 1.8 ou django 1.9 (btw, un passage sur http://zds.francoisdambrine.me vous permettra de corriger)
  • un POC plutôt sympa d'un outil qui se base sur codemirror pour rendre l'éditeur plus sympa
  • une demande forte pour l'upload des fichiers via glisser/déposer.

Alors la question "est-ce qu'on met les blocs ou pas" elle est un peu superficielle non?

  1. Si les blocs sont déjà codés cool.
  2. S'ils ne le sont pas, ils ne sont clairement pas prioritaires.
  3. S'ils ne le sont pas mais que j'ajout de la fonctionnalité de téléchargement d'image est suffisamment simple à ajouter pour la sortie de la v18 pourquoi s'en passer?

Ouais mais le faire par étape, entraîne une perte des boutons blocs pendant un certain temps !

Situphen

Rien n'empeche d'avoir les boutons sans que ça fasse une stylisation des blocs. L'éditeur actuel propose des boutons pour les blocs pourtant rien n'est rendu. Je vois pas le soucis.

Ouais mais le faire par étape, entraîne une perte des boutons blocs pendant un certain temps !

Situphen

Rien n'empeche d'avoir les boutons sans que ça fasse une stylisation des blocs. L'éditeur actuel propose des boutons pour les blocs pourtant rien n'est rendu. Je vois pas le soucis.

Kje

Ah, tu parles seulement de la stylisation des blocs. Au temps pour moi, alors ! :)

+0 -0

Hello !

J'ai réorganisé le code pour que l'éditeur marche sur plusieurs "backend", c'est à dire qu'il puisse fonctionner autant avec CodeMirror, qu'avec un Textarea simple, juste en codant une petite interface entre les deux.

Du coup, mon éditeur fonctionne avec ou sans CodeMirror ; sachant que sans, on sacrifie les features type le feedback visuel de ce qu'on est en train de taper, les sélecteurs multiples, les undos corrects, etc.

Aussi, j'ai pas encore implémenté les keybindings que j'avais mis en place, puisqu'avant, c'était CodeMirror qui s'en occupait.


Avec un textarea simple, on enlève quand même 60Kb de JS (on passe de 68Kb -> 8Kb minifié + gzippé). Comme je trouve que ça serait bête de ne pas profiter de ce que permet CodeMirror, on peut tout à fait imaginer de charger CodeMirror en asynchrone, puis l'utiliser une fois qu'il a été chargé (ce qui arrive donc que la première fois, vu que le navigateur met en cache ce genre de resources), si on est pas sur mobile (le support des mobiles de CodeMirror est assez hasardeux).

Duh, presque 2h, je vais avoir du mal à me lever demain, moi

+3 -0

Ça avance, ça avance encore

Déjà, j'ai implémenté les deux-trois trucs qui manquait à la version sans CodeMirror de l'éditeur, comme les raccourcis clavier, et un vrai historique de Ctrl-Z.

Ensuite, j'ai implémenté tout un tas de trucs autour des listes et de l'indentation. Si on appuie sur Enter, ça va continuer une liste, avec son indentation, en augmentant son "numéro" s'il s'agit d'une liste ordonnée. Si par contre, on veut pas continuer la liste, une deuxième pression sur Enter permet de sortir de la liste, et continuer sur le paragraphe suivant. Et comme j'ai pensé à a peu près tous les cas, ça marche aussi quand on est dans une citation. \o/

J'ai aussi implémenté le Tab pour indenter. Si on est dans une liste, ça indente la ligne courante/sélectionnée de 2 ; sinon de 4. Si on est pas dans une liste, et avec rien de sélectionné, ça va faire une indentation "intelligente" qu'on retrouve dans la plupart des éditeurs, qui va rajouter 1 à 4 espaces, pour qu'on soit toujours aligné sur les "colonnes de tabulations" (aucune idée de comment on peut appeler ça, mais je pense que vous avez compris le principe c: ). Avec le Tab vient forcément le Shift-Tab pour désindenter.

Je vais sûrement mettre en place une option pour désactiver le Tab pour indenter, qui garde le comportement par défaut du navigateur, si certains préfèrent. Je sais que sur Mac, par exemple, Alt-Tab permet de quand même avoir le comportement par défaut de Tab, et donc passer le focus au prochain élément (mais c'est évidemment pas le cas sur toutes les plateformes :-° ).

A part ça, j'ai ajouté quelques tests (j'dois être à un truc genre 60% de code couvert par les tests), et implémenté le hot-swap d'adapteur, ce qui permet de switcher à la volée entre CodeMirror et un textarea standard, ce qui sera pratique pour charger CodeMirror en asynchrone ^^

Pour le reste, suffit de regarder l'historique de commits depuis la dernière fois :)

Demo: avec et sans CodeMirror

Voila, après 1 semaine de boulot, j'attends avec impatience vos avis/retours :D


EDIT: Commit du soir, bonsoir

Je viens de rajouter une genre de prédiction de type de liste à l'indentation. C'est à dire que quand on (dés)indente une liste, l'éditeur va regarder dans cette même liste s'il on a déjà des éléments de la liste avec la même indentation, pour utiliser ça comme "type de liste". Par exemple: (le | représente le curseur)

1
2
3
4
5
6
 - élément 1
 - élément 2
   1. sous élément 2.1
   2. sous élément 2.2
 - élément 3
 - |

si on fait |Tab| à ce moment la, on va obtenir:

1
2
3
4
5
6
 - élément 1
 - élément 2
   1. sous élément 2.1
   2. sous élément 2.2
 - élément 3
   1. |

Ca marche aussi en désindentant, et ça reprend la numérotation si on est dans la même sous-liste. Par exemple:

1
2
3
4
5
6
 1. élément 1
 2. élément 2
   - sous élément 2.1
   - sous élément 2.2
 3. élément 3
   - |

si on fait |Shift-Tab| à ce moment la, on va obtenir:

1
2
3
4
5
6
 1. élément 1
 2. élément 2
   - sous élément 2.1
   - sous élément 2.2
 3. élément 3
 4. |

Bien sûr, c'est "local" à la liste en cours ; les listes plus haut dans un message sont pas prises en compte.

Ma question du coup, c'est est-ce que c'est une feature utile, ou alors un truc qui risque d'être plus relou qu'autre chose ? Parce que ça peut éventuellement gêner pour des trucs genre quand on fait des listes hybrides, des fois des listes ordonnées, des fois non… Aussi, on peut très bien imaginer un paramètre pour désactiver ce comportement :)

+5 -0

BUG : Quand j’entre une tabulation hors liste, que je tape du texte, puis que je reviens à la ligne, toute la ligne que je viens de taper est supprimée. Donc impossible d’utiliser les tabulations pour écrire directement du code, par exemple.

BUG (sans doute lié) : Quand je tape une première ligne de liste, puis que je reviens à la ligne, au lieu de me créer une deuxième ligne de liste, elle me supprime celle que je viens de taper. Si j’entre plusieurs lignes de texte, puis que je rajoute les tirets devant pour en faire une liste, puis que je reviens à la ligne à la fin de la dernière ligne, seule cette dernière est supprimée.

BUG (?) : il n’y a rien dans les boutons, j’ai dû faire des essais pour savoir à quoi chacun correspond.

Problèmes constatés dans les deux versions de l’éditeur. Linux Mint 17, Firefox 44.0.2, diverses extensions qui ne devraient en principe pas concerner ton site.

+1 -0

BUG : Quand j’entre une tabulation hors liste, que je tape du texte, puis que je reviens à la ligne, toute la ligne que je viens de taper est supprimée. Donc impossible d’utiliser les tabulations pour écrire directement du code, par exemple.

BUG (sans doute lié) : Quand je tape une première ligne de liste, puis que je reviens à la ligne, au lieu de me créer une deuxième ligne de liste, elle me supprime celle que je viens de taper. Si j’entre plusieurs lignes de texte, puis que je rajoute les tirets devant pour en faire une liste, puis que je reviens à la ligne à la fin de la dernière ligne, seule cette dernière est supprimée.

BUG (?) : il n’y a rien dans les boutons, j’ai dû faire des essais pour savoir à quoi chacun correspond.

Problèmes constatés dans les deux versions de l’éditeur. Linux Mint 17, Firefox 44.0.2, diverses extensions qui ne devraient en principe pas concerner ton site.

Dominus Carnufex

Ca m'apprendra à commit à 1h du mat' sans tester c:

J'ai aussi fixé le bug pour les boutons (pareil, ça m'apprendra à dev sous Chrome sans tester pour les autres navigateurs)


J'ai aussi implémenté le Tab pour indenter.

Comment fait-on alors pour naviguer au clavier ?

SpaceFox

C'est pour ça que je parlais d'une option désactivable. On peut même imaginer une option pour l'activer uniquement quand on est dans une liste, dans un bout de code, ou avec du texte sélectionné, et garder le comportement natif dans tous les autres cas.

Pour le reste, je pense que une fois qu'on est dans l'éditeur, l'important, c'est d'éditer du texte correctement, et je pense que les seules actions éventuellement utiles en dehors de l'éditeur dans ces cas la, c'est l'aperçu, et le bouton envoyer, qui seront accessibles par raccourcis clavier (Ctrl-Enter pour envoyer ; je sais pas encore pour l'aperçu). Du coup, je trouve pas ça choquant d'utiliser Tab pour indenter, tant qu'on laisse l'option pour désactiver ce comportement à l'utilisateur.

Aussi, si le souci c'est "une fois que j'ai fait Tab et que j'arrive dans l'éditeur, si je fais Tab tout de suite après, je reste dans l'éditeur, alors que je voulais atteindre les liens de pied de page", je peut aussi faire que si on appuie sur Tab alors qu'on vient de rentrer dans l'éditeur, que ça garde le comportement natif du Tab.

+0 -0

@Thunderseb: normalement, c'est fixé depuis mon dernier commit (il y a 4h, donc) ; sûrement donc que tu avais pas la dernière version à ce moment la


A part ce genre de bugs (même si ce genre de retour sert énormément, puisque j'ai pas encore mis en place de tests d'intégration automatiques sur tous les navigateurs, donc j'ai aucune idée de si tout fonctionne sur IE10, par exemple :-° ) ; des avis, des suggestions ? Je vois que je reçois des +1 sur mes messages, ça fait vachement plaisir, mais ça me permet pas de savoir si c'est parce qu'une en feature particulier plaît, ou si c'est parce que ça avance globalement ; si vous dites rien, je peux pas savoir ce qui est prioritaire, ce que les gens veulent comme killer-feature, ce qui doit être désactivable dans ce que je fais, ou ce qui manque vraiment par rapport à l'éditeur actuel… Ou si ce que je propose par exemple par rapport au Tab est utile à dev ou non… Des retours, je veux des retours ! ^^

+0 -0

Dans la version avec CodeMirror, les boutons sont toujours vides chez moi.

Sinon, concernant le Tab, il y a juste un détail : dans une liste, tu n’avances que de 2 tabulations, or notre Markdown en a besoin de 4 pour fonctionner. Compare le résultat de ces deux codes.

1
2
3
4
5
1. toto
2. tata
  - tutu
  - titi
3. tete
  1. toto
  2. tata
  3. tutu
  4. titi
  5. tete
1
2
3
4
5
1. toto
2. tata
    - tutu
    - titi
3. tete
  1. toto
  2. tata
    • tutu
    • titi
  3. tete

Pour le reste, j’utilise très peu l’éditeur de Markdown, ayant l’habitude de (presque) tout taper à la main, du coup, j’aurais du mal à te dire ce qui est bien ou non, utile ou non, ou quelque chose que je voudrais voir présent. :)

+0 -0

Quand tu dit label, tu parle du texte du bouton ? Parce que avec Firefox Developer Edition 46, j'ai pas de problème.

Bat'

Effectivement, je viens juste de màj Firefox Dev et ça fonctionne. Mais malgré le "fix", ça ne fonctionne tjs pas sous Firefox "normal" ^^ .

Au niveau des features, est-ce que tu penses inclure un outil pour faire/éditer les tableaux facilement ? (parce que bon, ça, c'est vraiment le truc chiant à manipuler en MD).

Et si tu savais inclure les choses que j'envisageais d'inclure dans la toolbar actuelle :

  • menu avec les caractères spéciaux
  • bouton pour du code inline (parce que cet accent `, c'est juste la misère à faire avec un clavier Azerty-belge).

Tu comptes aussi mettre les fenêtres "modales" pour insérer les liens, les images.. comme actuellement ?

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte