Meus usuários começaram a reclamar imediatamente de uma coisa irritante. Eles param de escrever imediatamente quando precisam, digamos, colocar algo em negrito, tocar duas vezes em uma palavra, clicar em B e continuar escrevendo. Claro, um novo toque em B para parar o uso de negrito — e dar um espaço, uma vírgula, uma nova palavra, o que for, para não selecionar antes de colocar em negrito, faz o truque.
Longe de ser o principal, no entanto.
Para começar - isso parece muito bom!
No entanto, eu gostaria de adicionar um tijolo à pequena parede de comentários dizendo que se deve sempre ter uma opção para voltar ao modo de entrada “cru”. Talvez eu seja old-school 
E um pequeno relatório de bug (esperado, mas vale a pena apontar): No novo modo, você tem opções limitadas para editar seu texto com um prompt que se concentra na formatação:
Ohh a quantidade de debate filosófico que esse comentário abrange 
Muito bom! Muitos usuários acham o Discourse “muito técnico” e acho que o editor WYSIWYG pode ajudar muito!
Então, agora é “só” implementar o editor WYSIWYG para diagramas Mermaid!
Ou, se isso for muito difícil, acho que este é o único que não apenas torna o bloco de código colorido, mas realmente exibe algo completamente diferente. A visualização de dois lados funciona bem ali. Acho que deveria funcionar dentro do editor, sem a necessidade de mudar para o modo antigo. Não tenho certeza de como, porém.
Isso está olhando um pouco mais para o futuro do que planejamos completamente. Acho que é provável que ofereçamos uma preferência do usuário para habilitar o alternador de Markdown, mas isso não está definido em pedra neste momento. Agradeço por compartilhar sua opinião aqui, é uma entrada útil.
É um recurso experimental, então prossiga por sua conta e risco. Pedimos que compartilhe qualquer feedback aqui para manter tudo em um só lugar para nós, isso facilitará muito nossas vidas
Não consigo reproduzir isso. Meu rascunho é salvo ao clicar em um link. Mas, trabalharemos em uma UI de Link (veja a seção 
Recursos ausentes) para que isso ajude a descobrir como editar o link.
Entendo o problema que você está descrevendo, mas não tenho certeza do que fazer a respeito. Testei esse cenário no Google Docs e no Notion, e ambos têm a mesma experiência (ou seja, depois de destacar uma palavra e ativar o negrito, todas as palavras que você digitar após mover o cursor para fora dessa palavra também ficam em negrito). Acho que isso é apenas uma consequência do uso de um editor de rich text e da incapacidade de ver claramente onde a formatação termina.
Atalhos de teclado (CMD+B) estão disponíveis e escrever Markdown ainda funciona, se isso ajudar. Continuarei pensando nisso para ver se há uma solução melhor. Como o Obsidian lida com a edição vem à mente, mas não seria simples para nós alcançar isso neste momento.
Diagramas Mermaid podem estar um pouco distantes — mas anotando seu interesse e adicionando-o como um Recurso ausente.
Capturei o feedback sobre a remoção de títulos 
Consigo reproduzir isso com oneboxes inline, vou verificar isso hoje, apenas para evitar a navegação para longe até que trabalhemos na UI para alternar entre links/oneboxes.
Tentei copiar mensagens de chat para um tópico.
Mudar para markdown corrigiu isso, então não é um grande problema neste momento.
Citações/transcrições de chat ainda não são suportadas, mas estamos trabalhando nisso.
Algo que notei é que tocar duas vezes na barra de espaço no iOS e macOS às vezes não cria um ponto final como deveria, no modo WYSIWYG.
Originalmente, escrevi que isso nunca acontece, mas acabou de acontecer comigo. Então, parece um bug? Mais alguém pode confirmar?
Isso parece uma ótima melhoria para nós, pessoal não técnico, equipe do Discourse. Obrigado
Notei que se eu começar uma linha com quatro espaços, ela automaticamente a transforma em código (e então negrito e itálico não funcionam mais).
Ele lerá os espaços como caracteres reais se eu usar até três no início? Ainda assim, não o suficiente para o meu caso de uso. editar: ele não considera os espaços como caracteres.
Existe uma maneira para que o botão Tab funcione como no Google Docs e no Word? Ou para usar quantos espaços eu quiser sem perder as opções de formatação? Isso seria especialmente especial ao colar coisas de um arquivo Docs, por exemplo, para que se parecesse mais com a forma como ficou na versão original.
Além disso, isso parece uma boa ideia:
Além disso, eu não costumo usar cores, mas poderia ver que isso é importante para algumas pessoas. Você acha que chegará lá?
É tudo de mim por agora. Obrigado novamente!
Estamos apenas sendo consistentes com a forma como ficará quando você publicar – uma linha iniciada com 4 espaços será convertida em um bloco de código quando a postagem for publicada.
Não exatamente, não. No final, ainda estamos construindo um Markdown “embelezado” para depois ser processado para HTML, então apenas as coisas que já podem ser feitas com nosso processamento atual de Markdown→HTML serão suportadas neste novo editor.
Temos a oportunidade de construir novos tipos de conteúdo, é claro, mas eles também precisarão ser suportados por meio de Markdown bruto, pois essa é a nossa fonte da verdade.
Estou gostando muito do novo composer!
Um hábito que estou tendo que mudar é que não posso mais usar apenas shift-para cima ou shift-para baixo para selecionar o parágrafo atual em que estou. Eu não percebi com que frequência eu faço isso, mas eu faço o tempo todo, para excluir algum texto ou selecioná-lo e movê-lo.
Agora tenho que usar shift-para a esquerda ou shift-para a direita (ou shift-cmd-para a esquerda ou shift-cmd-para a direita) para selecionar o último trecho de texto na linha superior ou inferior. Se isso faz sentido. Caso contrário, ele começa a selecionar o próximo parágrafo.
Acho que este é um passo à frente para usuários não técnicos! Embora, como o @Canapin, eu vá levar um tempo para me acostumar com a mudança 
. Um alternador para mudar rapidamente entre o modo Markdown e o modo WYSIWYG seria definitivamente apreciado.
Como outros observaram, a área de edição no desktop poderia ser um pouco mais larga. E eu também encontrei o problema de não conseguir voltar ao texto normal depois de ter entrado em um título - talvez renderizá-lo apenas quando a linha for concluída e eu pressionar Enter seja uma opção? (Eu apreciaria não precisar usar o mouse para desfazer isso, e também parece consistente com a forma como outras tags só são renderizadas quando concluídas)
Adicionalmente:
Não consigo criar listas de vários níveis
Não tenho certeza de como indentar código em um bloco de código
O contraste do menu suspenso de idioma para blocos de código é um pouco baixo (captura de tela abaixo) - eu o perdi no início
A entrada de tabelas como markdown não parece funcionar (quando uma tabela foi criada no editor antigo, ela é renderizada corretamente)
Quando uma tabela é seguida por outro elemento de bloco (como citação), não é possível inserir uma nova linha após a tabela
Parece que não há suporte para notas de rodapé (acho que também há um bug com notas de rodapé no editor antigo - se eu tentar criar notas de rodapé 1 e 2, apenas a primeira é renderizada corretamente)
Se eu colar uma imagem da área de transferência, não tenho certeza de como criar texto alternativo, e também não saberia como mudar o tamanho da imagem.
Eu realmente gosto da forma como as listas de vários níveis funcionam. Basta começar a inserir o markdown como de costume e ele automaticamente inicia seu primeiro marcador. Em seguida, pressione Enter para criar o próximo. Tab para recuar. Apagar para mudar de marcador para número, etc. Shift-Tab para criar outro marcador.
Ok, obrigado! Acho que não tentei isso por causa da coisa do bloco de código e porque não funciona no editor antigo. Mas faz sentido da maneira como funciona no novo editor.
Lembrando: na verdade, seria legal se listas numeradas passassem por diferentes símbolos (por exemplo, primeiro nível = números, segundo nível = caracteres minúsculos, terceiro nível = numerais romanos, quarto nível = caracteres maiúsculos). Mas presumo que isso não esteja em pauta porque não faz parte das especificações CommonMark ou GFM?
Usei o novo composer algumas vezes recentemente e nem me lembrei e nem notei que agora era WYSIWYG; quero dizer com isso que foi tão natural para mim usá-lo que não pensei sobre isso enquanto escrevia 
como se o composer sempre tivesse sido assim, embora não fosse.
Nem me incomodei com a estreiteza da janela. 
Uma experiência realmente tranquila, e não tive bugs, mas meu uso foi apenas de conteúdo básico (texto, citações, formatação padrão).
Não sei se ainda é o caso mesmo com o composer regular, mas antes, a prévia era quase 100% idêntica à postagem definitiva. Lembro-me de reclamar um pouco há um tempo porque a largura da prévia era ligeiramente diferente da largura de uma postagem, o que tornava a prévia não exatamente idêntica ao conteúdo postado.
Agora, não tenho certeza se reclamaria se o composer fosse mais largo do que uma postagem, se for mais confortável de usar do que antes. 
Ok, esse é um bom ponto! Ter o conteúdo postado correspondendo ao conteúdo editado certamente minimizaria o atrito.
Neste caso, acho que preferiria que o conteúdo editado estivesse no mesmo eixo visual do conteúdo postado.
Bem, este não é um meio impresso, então o conteúdo postado não é (quase) idêntico para todos.
Comecei a trabalhar nisso ontem, espero que não seja muito complicado e que possamos ter algo em breve…
Essa citação de bate-papo não é um grande problema porque afeta principalmente moderadores e administradores, que sabem como voltar ao sistema antigo.
A funcionalidade de rodapé é mais importante.
Para ser honesto, essa foi apenas minha opinião, e eu realmente não sei como as coisas estão lá fora.
É engraçado. Meus usuários estavam reclamando de markdown e da falta de WYSIWYG antes. Agora, nenhum deles mudou para o novo sistema. Eu quase sei por quê. Quase todo mundo usa celulares e eles estavam realmente reclamando de imagens e não conseguiam ver nada além de markdown.
Eles não usam mais nada, e voltamos à minha antiga afirmação: precisamos de uma ferramenta para esconder e mostrar a barra de ferramentas. Usuários comuns estão acostumados ao estilo de redes sociais onde eles apenas escrevem texto puro, enviam, e isso é suficiente. E como o Discourse oferece isso, mais ou menos, eles não têm incentivos para mudar ou experimentar o novo sistema. Exceto para ver imagens no compositor, mas meu fórum não é tão carregado de imagens.
Os plebeus podem ser uma história diferente, mas eles não sabem sobre aquela troca mágica.
