Intégrer la typographie dans le traitement du markdown

Il suffit de verifier que le caractere qui precede n'est pas un autre signe de ponctuation qui necessite une espace.

Pour faire un peu avancer le bouzin, je trouve que c'est une très bonne idée, mais effectivement, le code du parseur actuel ne s'y prête absolument pas. D'ailleurs, ça doit être une option dans ledit parseur qui DOIT être désactivable dans le cas ou notre projet serait forké.

Au delà de ça, rien n'empêche par contre d'être plus subtil: actuelement, on peut télécharger une archive, la modifier et la ré-uploader. Ce comportement va être encore amélioré avec l'arrivé prochaine (on espère) de la ZEP-12, qui permettra à l'auteur de faire à peu près n'importe quoi. Du coup, rien n'empêche de coder un outil externe qui fait des grep/replace

Pour ce qui est de la solution proposée par Dominus Carnuflex concernant les guillemets et les points d'exclamation et d'interrogation, j'émets un doute. Il est fréquent d'oublier l'espace, même sécable. On doit donc aussi imaginer le cas suivant, qui ne me semble pas si tiré par les cheveux que ça. Marc ajouta:"Que tu es moche!"

-fex, sans -l-.

Sinon, c'est fait exprès que ce ne soit pas pris en compte. Dans un texte anglais, je vais écrire Marc added: “You are so ugly!”. Il ne faut pas qu'une espace insécable soit insérée avant les deux-points, ni avant le point d'exclamation. C'est le seul moyen simple pour que la typographie des langues étrangères soit respectée.

Du coup, ma position est simple : on est déjà en train de mettre en place un outil pour faire une bonne partie du travail de typo à la place des auteurs, on ne va pas non plus pousser Mémé dans les orties et vérifier tous les cas. Un auteur peut prendre la peine de vérifier qu'il y a bien une espace avant et après ses signes de ponctuation double, ça ne va pas le tuer.

Effectivement, c'est sans doute plus simple. Par contre dans ce cas là, il faudrait avoir sous la main un tuto qui résume les principales règles typographiques pour aider les auteurs à corriger leurs fautes typographiques.

Et sinon, désolé pour le lapsus

Et on ne pourrait pas faire ça en JS côté client en attendant un meilleur module Markdown ?

Concernant cette histoire de diff, peut-être cela sera-t-il rendu plus simple avec la ZEP-08 ?

J'arrive un peu tard, mais bon…

En lisant le début du topic j'ai l'impression que le problème est surtout lié à un problème de configuration clavier ou de manque d'outils.

Est-ce que ça pourrait pas être quelque chose d'intégrable à la ZEP-14 ?

Par exemple une liste de caractères pratiques ou tout simplement une fonction qui remplace à la volée certaines choses dans l'éditeur côté client (donc sans impact tant que ce n'est pas validé par l'utilisateur).