Mes utilisateurs ont immédiatement commencé à se plaindre d’une chose agaçante. Ils arrêtent d’écrire immédiatement lorsqu’ils ont besoin, disons, de mettre quelque chose en gras, de double-cliquer sur un mot, de cliquer sur B et de continuer à écrire. Bien sûr, un nouveau tapotement sur B arrête l’utilisation du gras — et donner un espace, une virgule, un nouveau mot, n’importe quoi avant de mettre en gras, fait l’affaire.
Bien loin du problème majeur, cependant.
Pour commencer, c’est vraiment très bien !
Cependant, j’aimerais ajouter une pierre à l’édifice des commentaires en disant qu’il devrait toujours y avoir une option pour revenir au mode de saisie “brut”. Peut-être suis-je à l’ancienne 
Et un petit rapport de bug (assez attendu, mais qui mérite d’être signalé) : Dans le nouveau mode, vous avez des options limitées pour modifier votre texte avec une invite axée sur la mise en forme :
Ohh la quantité de débats philosophiques que ce commentaire couvre 
Vraiment bien ! De nombreux utilisateurs trouvent Discourse « trop technique » et je pense que l’éditeur WYSIWYG pourrait beaucoup aider !
Alors maintenant, il suffit d’implémenter l’éditeur WYSIWYG pour les diagrammes Mermaid !
Ou si c’est trop difficile, je pense que c’est le seul qui ne se contente pas de colorer le bloc de code, mais affiche en fait quelque chose de complètement différent. La vue à deux volets fonctionne bien là-bas. Je pense que cela devrait fonctionner dans l’éditeur, sans avoir besoin de passer à l’ancienne méthode. Je ne sais pas trop comment cependant.
C’est une vision un peu plus lointaine que ce que nous avons entièrement planifié. Je pense qu’il est probable que nous offrirons une préférence utilisateur pour activer le basculement Markdown, mais ce n’est pas gravé dans le marbre à ce stade. J’apprécie néanmoins que vous partagiez votre opinion, c’est une contribution utile.
Il s’agit d’une fonctionnalité expérimentale, alors procédez à vos risques et périls. Nous vous demandons de bien vouloir partager vos commentaires ici afin de tout centraliser pour nous, cela nous facilitera grandement la vie
Je n’arrive pas à reproduire cela. Mon brouillon est sauvegardé lorsque je clique sur un lien. Cependant, nous allons travailler sur une interface de lien (voir la section 
Fonctionnalités manquantes) afin de faciliter la modification du lien.
Je comprends le problème que vous décrivez, mais je ne suis pas sûr de ce qu’il faut faire à ce sujet. J’ai testé ce scénario sur Google Docs et Notion, et les deux ont la même expérience (c’est-à-dire qu’après avoir surligné un mot et activé le gras, tous les mots que vous tapez après avoir déplacé le curseur hors de ce mot sont également en gras). Je pense que c’est juste une conséquence de l’utilisation d’un éditeur de texte riche et de l’incapacité de voir clairement où se termine la mise en forme.
Les raccourcis clavier (CMD+B) sont disponibles et l’écriture en Markdown fonctionne toujours, si cela peut aider. Je continuerai à y réfléchir pour voir s’il existe une meilleure solution. La façon dont Obsidian gère l’édition me vient à l’esprit, mais ce ne serait pas simple à réaliser pour nous pour le moment.
Les diagrammes Mermaid sont peut-être un peu plus loin — mais je note votre intérêt et l’ajoute comme une Fonctionnalité manquante.
J’ai recueilli les commentaires sur la suppression des titres 
Je peux reproduire cela avec des oneboxes inline, je vais regarder cela aujourd’hui, juste pour éviter de naviguer ailleurs jusqu’à ce que nous travaillions sur l’interface utilisateur pour basculer entre les liens/oneboxes.
J’ai essayé de copier des messages de chat dans un sujet.
Passer en markdown a résolu ce problème, donc ce n’est pas un problème majeur à ce stade.
Les citations / transcriptions de chat ne sont pas encore prises en charge, mais nous y travaillons.
J’ai remarqué que le double appui sur la barre d’espace sous iOS et macOS ne crée parfois pas de point comme il le devrait, en mode WYSIWYG.
J’avais initialement écrit que cela n’arrivait jamais, mais cela vient de m’arriver. Cela semble donc buggé ? Quelqu’un d’autre peut-il confirmer ?
Cela semble être une excellente amélioration pour nous, les non-techniciens, équipe Discourse. Merci
J'ai remarqué que si je commence une ligne avec quatre espaces, elle se transforme automatiquement en code (et les gras et italiques ne fonctionnent plus).
Lira-t-il les espaces comme des caractères réels si j’en utilise jusqu’à trois au début ? Toujours pas suffisant pour mon cas d’utilisation. edit : il ne considère pas les espaces comme des caractères.
Existe-t-il un moyen pour que la touche tabulation fonctionne comme dans Google Docs et Word ? Ou pour utiliser autant d’espaces que je veux sans perdre les options de mise en forme ? Ce serait particulièrement utile lors du collage d’éléments d’un fichier Docs, par exemple, afin que cela ressemble davantage à la version originale.
De plus, cela semble être une bonne idée :
De plus, je n’utilise généralement pas les couleurs, mais je peux voir que c’est important pour certaines personnes. Pensez-vous que vous y arriverez ?
C’est tout pour moi maintenant. Merci encore !
Nous nous contentons d’être cohérents avec la façon dont cela apparaîtra lors de la publication – une ligne commençant par 4 espaces sera convertie en bloc de code lorsque le message sera publié.
Pas vraiment, non. En fin de compte, nous construisons toujours un Markdown formaté pour ensuite le convertir en HTML, donc seules les choses qui peuvent déjà être faites avec notre traitement actuel Markdown→HTML seront prises en charge dans ce nouvel éditeur.
Nous avons l’opportunité de créer de nouveaux types de contenu, bien sûr, mais ils devront également être pris en charge via le Markdown brut, car c’est notre source de vérité.
J’apprécie vraiment le nouveau compositeur !
Une habitude que je dois changer est que je ne peux plus utiliser simplement Maj-haut ou Maj-bas pour sélectionner le paragraphe actuel sur lequel je me trouve. Je ne réalisais pas à quelle fréquence je faisais cela, mais je le fais tout le temps, pour supprimer du texte ou le sélectionner et le déplacer.
Je dois maintenant utiliser Maj-gauche ou Maj-droite (ou Maj-Cmd-gauche ou Maj-Cmd-droite) pour sélectionner le dernier morceau de texte sur la ligne du haut ou du bas. Si cela a du sens. Sinon, cela commence à sélectionner le paragraphe suivant.
Je pense que c’est un pas en avant pour les utilisateurs non techniques ! Bien que, comme @Canapin, il me faudra un peu de temps pour m’habituer au changement 
. Un bouton pour basculer rapidement entre le mode Markdown et le mode WYSIWYG serait certainement apprécié.
Comme d’autres l’ont noté, la zone d’édition sur ordinateur pourrait être un peu plus large. Et j’ai également rencontré le problème de ne pas pouvoir revenir à un texte normal une fois que j’ai entré un titre - peut-être ne le rendre qu’une fois la ligne terminée et que j’ai appuyé sur Entrée est une option ? (J’apprécierais de ne pas avoir à utiliser la souris pour annuler cela, et cela semble également cohérent avec la façon dont les autres balises ne sont rendues qu’une fois terminées)
De plus:
Je ne peux pas créer de listes à plusieurs niveaux
Je ne suis pas sûr de la façon dont j’indente le code dans un bloc de code
Le contraste de la liste déroulante de la langue pour les blocs de code est un peu faible (capture d’écran ci-dessous) - je l’ai manqué au début
L’entrée de tableaux en markdown ne semble pas fonctionner (lorsqu’un tableau a été créé dans l’ancien éditeur, il est rendu correctement)
Lorsqu’un tableau est suivi d’un autre élément de bloc (comme une citation), il n’est pas possible d’insérer une nouvelle ligne après le tableau
Il semble qu’il n’y ait pas de support pour les notes de bas de page (je pense qu’il y a aussi un bug avec les notes de bas de page dans l’ancien éditeur - si j’essaie de créer les notes de bas de page 1 et 2, seule la première est rendue correctement)
Si je colle une image du presse-papiers, je ne suis pas sûr de la façon de créer un texte alternatif, et je ne saurais pas non plus comment changer la taille de l’image.
J’aime beaucoup la façon dont fonctionnent les listes à plusieurs niveaux. Commencez simplement par mettre le markdown comme d’habitude et il commencera automatiquement votre première puce. Ensuite, appuyez sur Entrée pour créer la suivante. Tabulez pour indenter. Effacez pour passer de la puce au numéro, etc. Maj+Tab pour créer une autre puce.
Ok, merci ! Je suppose que je n’ai pas essayé cela à cause du truc des blocs de code et parce que cela ne fonctionne pas dans l’ancien éditeur. Mais cela a du sens de la manière dont cela fonctionne dans le nouvel éditeur.
Cela me rappelle : ce serait en fait bien si les listes numérotées passaient par différents symboles (par exemple, premier niveau = chiffres, deuxième niveau = lettres minuscules, troisième niveau = chiffres romains, quatrième niveau = lettres majuscules). Mais je suppose que ce n’est pas à l’ordre du jour car cela ne fait pas partie des spécifications CommonMark ou GFM ?
J’ai utilisé le nouveau compositeur plusieurs fois récemment et je ne me suis même pas souvenu et je n’ai pas remarqué qu’il était maintenant WYSIWYG ; je veux dire par là qu’il m’était si naturel de l’utiliser que je n’y ai pas pensé en écrivant 
comme si le compositeur avait toujours été ainsi, bien que ce ne soit pas le cas.
Je n’ai même pas été dérangé par l’étroitesse de la fenêtre. 
Une expérience vraiment fluide, et je n’ai pas rencontré de bugs mais mon utilisation était seulement du contenu basique (texte, citations, formatage standard).
Je ne sais pas si c’est toujours le cas même avec le compositeur habituel, mais avant, l’aperçu était presque identique à 100% au message définitif. Je me souviens m’être un peu plaint il y a quelque temps car la largeur de l’aperçu était légèrement différente de la largeur d’un message, ce qui rendait l’aperçu pas exactement identique au contenu publié.
Maintenant, je ne suis pas sûr que je me plaindrais si le compositeur était plus large qu’un message, si c’est plus confortable qu’avant à utiliser. 
Ok, c’est un bon point ! Avoir le contenu publié qui correspond au contenu édité minimiserait certainement les frictions.
Dans ce cas, je préférerais que le contenu édité soit sur le même axe visuel que le contenu publié.
Eh bien, ce n’est pas un support imprimé, donc le contenu posté n’est pas (presque) identique pour tout le monde.
J’ai commencé à travailler là-dessus hier, j’espère que ce ne sera pas trop compliqué et que nous aurons quelque chose bientôt…
Cette citation de discussion ne pose pas vraiment de problème car elle concerne principalement les modérateurs et les administrateurs, qui savent comment revenir à l’ancien système.
La fonction de note de bas de page est plus importante.
Honnêtement, ce n’était que mon point de vue, et je ne sais vraiment pas comment les choses se passent là-bas.
C’est drôle. Mes utilisateurs se plaignaient du markdown et du manque de WYSIWYG plus tôt. Maintenant, aucun d’eux n’a changé pour le nouveau système. Je commence à comprendre pourquoi. La presque totalité utilise des mobiles et ils se plaignaient en réalité des images et ne voyaient rien d’autre que du markdown.
Ils n’utilisent rien d’autre, et nous revenons à mon ancien argument : nous avons besoin d’un outil pour cacher et afficher la barre d’outils. Les utilisateurs réguliers sont habitués au style des réseaux sociaux où ils écrivent simplement du texte brut, l’envoient, et cela suffit. Et comme Discourse offre cela, en quelque sorte, ils n’ont aucune incitation à changer ou à essayer le nouveau système. Sauf pour voir des images dans le rédacteur, mais mon forum n’est pas très axé sur les images.
Les gens ordinaires pourraient avoir une histoire différente, mais ils ne connaissent pas cette magie de basculement.
