Serait-il difficile de remplacer l’éditeur de publication par défaut textarea par un surligneur de syntaxe markdown ?
Ou est-ce que je manque l’option quelque part ?
Vous avez déjà magnifiquement implémenté cela pour le CSS dans l’éditeur de styles d’administration :
N’est-ce pas déjà réalisé en utilisant le bloc de code, qui vous donne la coloration syntaxique dans la zone d’aperçu ?
C’est une idée intéressante, le but serait d’avoir une coloration syntaxique dans la zone de texte (c’est-à-dire le côté gauche de l’éditeur) afin de pouvoir voir si l’on fait des erreurs de syntaxe markdown. Oui, les blocs de code font la même chose dans l’aperçu, mais vous ne verrez aucune erreur markdown, par exemple. Et certains markdown complexes seraient plus faciles à parcourir, comme les posts avec beaucoup de tableaux, de téléversements, de liens, de titres.
Je ne suis pas sûr que ce soit facile à faire, cependant. Nos écrans d’administration utilisent l’ACE Editor, et je ne pense pas que nous puissions simplement le glisser-déposer sur l’éditeur de posts.
Oui, c’est exactement mon cas d’utilisation.
Cela donne un retour très direct sur votre syntaxe : vous n’avez pas à regarder le volet de droite toutes les deux secondes pour vérifier si vous ne faites pas d’erreurs de syntaxe triviales.
Cela donnerait un peu plus de structure à ceux qui sont moins aptes en Markdown (n’importe quel débutant).
Bien sûr, vous avez toujours le rendu HTML sur le côté droit de la fenêtre de composition.
Je ne vois aucun inconvénient immédiat à cela, surtout si c’est une option.
PS : Apparemment, il n’y a même pas de surligneur de syntaxe Markdown installé pour les blocs de code 
:
# La syntaxe des blocs de code Markdown...
... malheureusement ...
- n'est
- pas mise en évidence
**du tout** !
EDIT 2 heures plus tard : Corrigé par @pmusaraj
Ah, bonne remarque ! Il semble que nous ayons oublié certains styles pour le surligneur markdown.
Utiliser un éditeur complet pour du markdown « juste » n’est-ce pas un peu excessif ?
À mon avis, utiliser un semi-wysiwyg markdown correspond mieux aux besoins de l’OP, comme par exemple https://ui.toast.com/tui-editor, Playground | Milkdown, etc.
Ces deux-là sont superbes !
Cependant, j’imagine que le Milkdown plus simple conviendrait mieux, car il est acceptable que l’éditeur donne une impression plus « écran sous-marin »[^wp], puisque vous avez de toute façon l’aperçu à droite.
[^wp] : Oui, je me souviens très bien de WordPerfect 
Oui, n’importe lequel de ACE, TUI, Milkdown représente un très grand changement, ils nécessiteraient tous de remplacer la zone de texte par contenteditable. Cela vaut la peine d’être expérimenté, c’est certain, mais au cœur, c’est un projet d’envergure.
La PR est en ligne avec un correctif pour la coloration syntaxique manquante : UX: Update highlight.js styles by pmusaraj · Pull Request #23999 · discourse/discourse · GitHub
Pour développer, d’abord, c’est quelque chose que je veux vraiment que le cœur de Discourse prenne en charge, mais il est aussi utile de développer la complexité.
Le cœur de Discourse utilise de nombreuses API directement contre TEXTAREA, les @mentions, les insertions de la barre d’outils dans TEXTAREA, les téléchargements, le copier-coller d’images et plus encore.
Tout cela n’est pas abstrait et suppose qu’il communique avec un TEXTAREA. Ajouter directement un contenteditable là-bas signifierait qu’il faudrait également simuler un TEXTAREA de manière appropriée et très précise, quelque chose qui échouerait probablement. Nous avons besoin d’un travail considérable pour créer une sorte de framework de fournisseur afin de pouvoir remplacer des éléments.
Voir aussi :
Highlighter est certainement un excellent premier pas dans cette direction car vous n’avez pas à vous soucier du mappage bidirectionnel du markdown au texte.
Il pourrait y avoir une astuce de ninja où vous pouvez masquer le TEXTAREA puis rendre un contenteditable par-dessus, en transmettant les événements à l’original, mais même cela nécessiterait une réimplémentation du positionnement des @mention.
Je dois être honnête : maintenant que j’ai vu l’éditeur de Trello, Discourse fait un peu vieux jeu (années 2000) en matière d’éditeur :
Je pense que ce genre de chose est important.
Remarque : Il accepte toujours à 100 % la syntaxe Markdown.
Personnellement, je n’aime pas ça. C’est beaucoup trop encombré. J’adore que l’éditeur de Discourse soit visuellement épuré. Tout ce que je vois vraiment, c’est du texte, et le rendu est sur le côté, là où il doit être.
Pour en revenir au point principal de la coloration syntaxique, c’est quelque chose que j’aimerais aussi voir. Au minimum, j’aimerais que les # Titres et ## Sous-titres soient mis en évidence d’une manière ou d’une autre. Je ne peux pas vous dire combien de fois je parcours mes articles plus longs, où l’aperçu et l’éditeur sont désalignés, et il me faut des heures pour trouver où se trouve mon # titre pertinent.
Pour moi, rendre simplement les # Titres en gras, ou d’une couleur particulière dans la partie éditeur du compositeur serait une amélioration considérable.
C’est le cas, n’est-ce pas ?
Ces éditeurs sont faits pour les développeurs et les codeurs et sont vraiment déroutants pour les utilisateurs ordinaires.
Mais c’est ainsi et c’est trop ancré dans le noyau pour être changé. Comme la question brouillon 
Enfin — hors sujet etc.
Est-ce que cela se rapproche de sa réalisation ?
Contexte :
Nous avons commencé à travailler dans ce domaine @lindsey partagera des informations au fur et à mesure de notre progression
C’est une très bonne nouvelle - l’utilisation de Markdown est idéale pour nos utilisateurs expérimentés, mais représente une courbe d’apprentissage assez raide pour la majorité de nos utilisateurs moins expérimentés et contribuerait grandement à rendre notre communauté plus accessible.
Salut @lindsey, je ne veux pas te presser du tout, mais je me demandais si tu pouvais partager ce qui suit :
Si les changements incluront l’interopérabilité / un cadre pour permettre aux plugins de développer des solutions d’éditeur.
Dans le même ordre d’idées, si vous envisagez de développer votre propre éditeur de texte enrichi, par exemple dans un plugin.
Une idée approximative du calendrier que vous envisagez pour 1 et/ou 2.
Le contexte pour moi est l’approche et le calendrier de ce projet potentiel
@Rohail_Altaf et moi essayons de réfléchir à la meilleure façon d’aborder ce sujet, en particulier en ce qui concerne le calendrier. Néanmoins, je comprends tout à fait si vous ne pouvez pas partager cela à ce stade.
Salut Angus — désolé pour le retard, nous étions à la retraite annuelle de notre entreprise à Tokyo !
Je ne peux pas répondre avec trop de détails pour le moment car nous sommes encore en train de finaliser les détails de mise en œuvre. Je pense que nous aurons cela résolu dans les semaines à venir, du moins suffisamment pour répondre à ces questions, donc je reviendrai vers vous une fois que nous en saurons plus.
Discourse expédie maintenant un compositeur WYSIWYG expérimental 
Cette infrastructure rend également possible à long terme l’application de la coloration syntaxique sur le markdown si nous voulons suivre cette voie, bien qu’elle devienne beaucoup moins nécessaire avec le nouveau compositeur.
Par exemple, le nouveau compositeur vous permet maintenant d’appliquer la coloration syntaxique au code pendant que vous le tapez !
