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

Ne me fait pas dire ce que je n'ai pas dit: la coloration syntaxique, c'est le bien

Ce que vise principalement ma remarque, c'est les messages "sapin de noël" mode skyblog de jeune d'il y a 10 ans (mes yeux saignent encore rien que d'y repenser), et les gens qui mettent leur message en jaune pâle tout à fait illisible ou en rouge pêtant parce que "C 1portan !" (à fortiori, ce genre de comportement arrive, dans une moindre mesure quand quelqu'un met l'ensemble du message en gras, mais c'est un peu moins choquant). C'est donc aussi une histoire de cohérence graphique.

Après, je suis d'accord que dans ce genre de cas, ça manque.

EDIT: il faut savoir aussi que c'est ce genre de raisonnement qui fait que ce n'est pas présent dans le markdown de base, ce n'est donc pas spécifique à ZdS (je viens d'aller vérifier)

Normalement c'est l'accent dans un liens qui génère la 500.

Mais on peut être aussi plus imaginatif :

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

ou :

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

ou :

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

Mon avis en termes de philosophie ne portait pas sur la coloration syntaxique, ni même la couleur tout court d'ailleurs, mais sur tout le reste de la phrase "quand c'est mal utilisé, ça mène à n'importe quoi, donc on l'empêche". Avec une philosophie pareille, je ne beurrerais jamais de tartine

Toute la question est de savoir si on prend les utilisateurs pour des irresponsables ou bien des personnes capables d'une auto-discipline communautaire en leur mettant des outils complets à disposition. Si j'en crois le dernier bilan, retranscrit pendant l'AG notamment, la communauté semble suffisamment mature à ce niveau, et la modération n'est à faire qu'au compte-goutte.

Et si la question se pose dans les forums, elle ne se pose certainement pas dans la rédaction d'articles .

Bon plus sérieusement, pour le markdown on a choisit d'avoir un langage de balisage à sémantique. L'idée étant que pour avoir des contenu harmonieux, il faut essayer d'éviter aux auteurs de faire la mise en page. On peut toujours en reparler mais pas dans ce sujet je pense.

Je suis désolé, je n'ai vraiment pas le temps de lire les 4 pages là tout de suite mais Eskimon m'a linké cette ZEP suite à la création d'une issue que j'ai posté sur le dépôt GitHub du projet. Donc, je me permet de copier coller mon message et je m'en excuse.

Aujourd'hui, je me concentre beaucoup plus sur le contenu de ZdS, notamment dans le cadre de ce projet.

Je suis donc passé de l'autre côté de la "barrière" : utilisez ce que nous développons. Je peux vous dire que l'éditeur est juste horrible à utiliser pour écrire du contenu. J'ai identifié plusieurs raisons :

• La zone de saisie est minuscule. La première chose que je fais, c'est l'étendre au maximum de l'écran pour avoir une vision globale de ce que je fais.
• Aucun retour visuel de ce que je fais. Je dois toujours cliquer sur "Aperçu", regardez ce que ça donne puis, à nouveau, agrandir ma zone de saisie parce qu'elle se réduit automatiquement.
• Aucune sauvegarde automatique de ce que j'écris. Je ne compte plus le contenu que je perds rien qu'avec un rafraichissement accidentel. C'est très très très frustrant de perdre un contenu de plusieurs pages.

Donc globalement, qu'est ce que je fais ? J'ouvre stackedit.io et j'écris mon contenu là dessus. Puis, quand j'ai terminé, je copie colle dans ZdS.

Alors, je vois 2 améliorations possibles :

• Il faut améliorer notre éditeur (voir point suivant) mais aussi être compatible avec d'autres éditeurs Markdown. Je ne sais pas du tout comment ça fonctionne techniquement mais je sais que stackedit et Google Doc peuvent se lier pour créer du contenu. Les documents Google Doc peuvent automatiquement rediriger vers un document stackedit.
• Améliorer notre éditeur en consacrant une page entière pour ça, en retirant la sidebar et conserver juste l'en-tête, l'éditeur à gauche et le rendu à droite.

Je tag back aussi parce que je pense qu'il peut y avoir des tâches Back aussi. Notamment ce qui est lié à la sauvegarde des textes d'un utilisateur.

Effectivement, c'est pas mal de retour déjà connus, mais ça fait pas de mal de répéter.

Par contre pour ce qui est de l'intégration à d'autres services (Drive, Dropbox…), je vois pas trop l'intérêt à part introduire des dépendances supplémentaires à des sites externes. Même si effectivement ça pourrait être pratique, ça ne ferait que supprimer un copier-coller…

Par contre pour ce qui est de l'intégration à d'autres services (Drive, Dropbox…), je vois pas trop l'intérêt à part introduire des dépendances supplémentaires à des sites externes. Même si effectivement ça pourrait être pratique, ça ne ferait que supprimer un copier-coller…

Je ne parlais pas avec des services de stockage mais avec d'autres éditeurs Markdown pour laisser le choix aux utilisateurs de choisir. Ca me semble d'autant plus important si notre éditeur à nous est tout pourrie comme c'est le cas pour l'instant.

Mais c'est vrai que ça rajoute des dépendances en plus mais est-ce un problème ?

Le but de le ZEP est justement d'améliorer l'éditeur actuel. Donc normalement on ne devrait pas avoir besoin d'autres éditeurs.

Ajouter des dépendances force à les tenir à jour régulièrement mais implique aussi que le jour où elles ne sont plus maintenues il faudra soit les maintenir nous-mêmes soit les remplacer. C'est pas mal de travail supplémentaire pour pas grand chose.

Une fois l'éditeur actuel refait ça devrait déjà aller mieux, rassure-toi.

Est-on obligé de faire notre propre éditeur ? N'en existe-t-il pas qu'on pourrait reprendre ? Quitte à coder et à maintenir du code, autant le faire à partir d'une bonne base, utilisée par d'autres gens que ZdS, non ?

Je dis ça comme ça, je ne me suis pas renseigné sur les éditeurs existants.

Il y en a (comme markItUp!), mais ils ne supportent pas le MarkDown propre à ZdS, donc il faudra bien le customizer.

Autant partir sur un truc sur mesure qui sera plus optimisé (pas d'options inutiles, donc pas de calculs inutiles) et mieux intégré.

Et on ne peut pas rendre markItUp ou autre plus général ? On aurait un module JS auquel on fournirait notre syntaxe markdown et il se chargerait de créer les boutons.

Je ne connais pas le fonctionnement derrière l'éditeur, mais un truc du genre ne pourrait-il pas faire l'affaire ?

1
2
3
4
5
6
7

Editor({
    "gras": {
        "start": "**",
        "end": "**",
        "icon": "url"
    }
})

Il faut par contre avoir un moyen de décrire notre syntaxe. En s'inspirant de pandoc ?

J'espère de pas dire de grossièretés…

Effectivement, ça pourrait. Après il faut voir si l'ensemble des points de la ZEP peuvent être intégrés (aperçu en temps réel, mode plein écran, etc.).

Il faudrait faire un test pour le coup. À voir quand j'aurai installé le code en local

C'est déjà comme ça que l'éditeur actuel fonctionne. Perso je ne vois pas non plus l'intérêt d'un n-ième truc externe à charger en plus. Le script actuel fonctionne correctement, il manque juste quelques features qui n'ont rien de bien compliqué à implémenter.

Certaines features impliquent quand même des changements conséquents, comme l'upload en drag'n'drop avec mise à jour de l'URL après upload (façon GitHub).

L'aperçu live est aussi différent des principaux systèmes clé en main : apparemment un système à base de sockets serait prêt à être utilisé, plutôt que de simples XHR ou autres iframes.

J'ai rien contre l'idée d'un plugin, mais ça me paraît dangereux de mettre le nez dans un code externe pour en modifier la moitié quand on pourrait tout maîtriser et avoir un truc sur mesure propre.

Ouais, l'upload par dnd est plus complexe. Mais pas si compliqué que ça, du moins pour la partie JS.

Et pour l’aperçu, le plus simple reste XHR. Un simple bouton "Visualisation", une requête XRH et hop. Un aperçu au cours de la frappe n'est pas nécessaire (mais dans ce cas ce serait mieux avec sockets). Mais là aussi, tout se joue côté back-end, c'est simple côté JS.

J'ai pas dis que c'était compliqué en soi, juste que c'était pas forcément simple à incorporer dans un plugin générique, pas forcément prévu pour ce genre d'usages…

Et l'aperçu en temps réel est une demande de la ZEP, donc difficile de passer à côté.

Et l'aperçu en temps réel est une demande de la ZEP, donc difficile de passer à côté.

Je confirme, autant que le mode plein écran avec l'éditeur à droite et l'aperçu à gauche. Ca fait du boulot tout ça.

C'est pas plutôt l'inverse ?

Mais oui, c'est plusieurs petits trucs qui, mis bout-à-bout, vont prendre un peu de temps quand même…

Après l'aperçu en temps réelle, n'était aucunement dans la ZEP initiale ! Il a été rajouté plus tard, car ça a été évoqué ! Et, il me semble qu'il a été dit, quelque part, que ce n'était pas la priorité ultime, alors bon.. Mais si c'est réellement un besoin ultime et qui se fait plébisciter pourquoi pas !

Autant prévoir l'évolution dès maintenant, car à terme ça risque quand même d'être demandé, surtout pour la rédaction des articles et tutoriels… Même si elle n'est pas forcément développée ou intégrée dès le début.

Moi en tout cas, c'est ce que j'aimerais mais après avoir lu le premier message, je vois que non. Chose que je trouve dommage parce que j'ai très rarement besoin de savoir ce que je fais sur la largeur mais plutôt sur la hauteur.

Faire une ZEP rien que pour des smileys, des raccourcis et l'ajout d'images, autant créer 3 issues "Evolution" sur le dépôt GitHub.