Mis usuarios empezaron a quejarse de inmediato de una cosa molesta. Dejan de escribir de inmediato cuando necesitan, digamos, poner algo en negrita, tocar dos veces una palabra, hacer clic en B y continuar escribiendo. Claro, un nuevo toque en B detiene el uso de negrita, y al dar un espacio, una coma, una nueva palabra, lo que sea, antes de poner en negrita, funciona.
Lejos de ser el principal, sin embargo.
Para empezar, ¡esto se ve muy bien!
Sin embargo, me gustaría añadir un ladrillo al pequeño muro de comentarios diciendo que siempre se debe tener la opción de volver al modo de entrada “crudo”. Quizás soy anticuado 
Y un pequeño informe de error (algo esperado, pero vale la pena señalarlo): En el nuevo modo, tienes opciones limitadas para editar tu texto con un aviso que se centra en el formato:
Ohh la cantidad de debate filosófico que cubre ese comentario 
¡Muy bueno! Muchos usuarios encuentran Discourse “demasiado técnico” y creo que el editor WYSIWYG podría ayudar mucho.
¡Así que ahora solo hay que implementar el editor WYSIWYG de diagramas Mermaid!
O si eso es demasiado difícil, creo que este es el único que no solo hace que el bloque de código sea colorido, sino que en realidad muestra algo completamente diferente. La vista de dos lados funciona bien allí. Creo que debería funcionar dentro del editor, sin necesidad de cambiar a la forma antigua. No estoy seguro de cómo, sin embargo.
Esto es mirar un poco más allá en el futuro de lo que hemos planeado por completo. Creo que es probable que ofrezcamos una preferencia de usuario para habilitar el interruptor de Markdown, pero eso no está grabado en piedra en este momento. Sin embargo, aprecio que compartas tu opinión aquí, es una entrada útil.
Es una función experimental, así que procede bajo tu propio riesgo. Te pedimos que compartas cualquier comentario aquí para mantener todo en un solo lugar para nosotros, ¡eso nos facilitará mucho la vida!
No puedo reproducir esto. Mi borrador se guarda al hacer clic en un enlace. Pero, trabajaremos en una interfaz de usuario de enlaces (ver la sección 
Funciones faltantes) para que eso ayude a averiguar cómo editar el enlace.
Entiendo el problema que describes, pero no estoy seguro de qué hacer al respecto. Probé este escenario en Google Docs y Notion, y ambos tienen la misma experiencia (es decir, después de resaltar una palabra y activar la negrita, todas las palabras que escribes después de mover el cursor fuera de esa palabra también están en negrita). Creo que esto es solo una consecuencia de usar un editor de texto enriquecido y no poder ver con tanta claridad dónde termina el formato.
Los atajos de teclado (CMD+B) están disponibles y escribir Markdown todavía funciona, si eso ayuda. Seguiré pensando en esto para ver si hay una mejor solución. Cómo Obsidian maneja la edición viene a la mente, pero no sería fácil para nosotros lograrlo en este momento.
Los diagramas de Mermaid pueden estar un poco más adelante, pero tomo nota de tu interés y lo agrego como una Función faltante.
He capturado los comentarios sobre la eliminación de encabezados 
Puedo reproducir esto con oneboxes en línea, lo revisaré hoy, solo para evitar la navegación hasta que trabajemos en la interfaz de usuario para alternar entre enlaces/oneboxes.
Intenté copiar mensajes de chat a un tema.
Cambiar a markdown solucionó eso, así que no es un problema importante en este momento.
Las citas/transcripciones de chat aún no son compatibles, pero estamos trabajando en ello.
Algo que he notado es que al tocar dos veces la barra espaciadora en iOS y macOS a veces no crea un punto final como debería, en modo WYSIWYG.
Originalmente escribí que nunca lo hace, pero acaba de hacerlo. ¿Así que parece un error? ¿Alguien más puede confirmarlo?
Esto parece una gran mejora para nosotros, los no técnicos, equipo de Discourse. Gracias
Noté que si empiezo una línea con cuatro espacios, automáticamente la convierte en código (y entonces los negrita y cursiva ya no funcionan).
¿Leerá los espacios como caracteres reales si uso hasta tres al principio? Aún así, no es suficiente para mi caso de uso. edición: no considera los espacios como caracteres.
¿Hay alguna forma de que el botón de tabulación funcione como lo hace en Google Docs y Word? ¿O de usar tantos espacios como quiera sin perder las opciones de formato? Esto sería especialmente especial al pegar cosas de un archivo de Docs, por ejemplo, para que se pareciera más a cómo se veía en la versión original.
Además, esta parece una buena idea:
Además, no suelo usar colores, pero podría ver que es importante para algunas personas. ¿Crees que llegarán a eso?
Eso es todo por mi parte. ¡Gracias de nuevo!
Estamos siendo consistentes con cómo se verá cuando lo publiques: una línea que comience con 4 espacios se convertirá en un bloque de código cuando se publique la entrada.
En realidad no. Al final, todavía estamos construyendo un Markdown embellecido para luego ser procesado a HTML, por lo que solo se admitirán en este nuevo editor las cosas que ya se pueden hacer con nuestro procesamiento actual de Markdown a HTML.
Tenemos la oportunidad de crear nuevos tipos de contenido, por supuesto, pero también deberán ser compatibles a través de Markdown sin procesar, ya que esa es nuestra fuente de verdad.
¡Estoy disfrutando mucho del nuevo compositor!
Un hábito que tengo que cambiar es que ya no puedo usar shift-arriba o shift-abajo para seleccionar el párrafo actual en el que estoy. No me di cuenta de la frecuencia con la que hago esto, pero lo hago todo el tiempo, para eliminar texto o seleccionarlo y moverlo.
Ahora tengo que usar shift-izquierda o shift-derecha (o shift-cmd-izquierda o shift-cmd-derecha) para seleccionar el último trozo de texto en la línea superior o inferior. Si eso tiene sentido. De lo contrario, comienza a seleccionar el siguiente párrafo.
¡Creo que este es un paso adelante para los usuarios no técnicos! Aunque, al igual que @Canapin, me llevará un poco de tiempo acostumbrarme al cambio 
. Se agradecería un interruptor para cambiar rápidamente entre el modo Markdown y el modo WYSIWYG.
Como otros señalaron, el área de edición en el escritorio podría ser un poco más ancha. Y también me encontré con el problema de no poder volver al texto normal una vez que he introducido un encabezado: ¿quizás solo renderizarlo una vez que la línea esté completa y presione Enter? (Agradecería no tener que usar el ratón para deshacer esto, y también se siente coherente con la forma en que otras etiquetas solo se renderizan una vez que se completan).
Además:
No puedo crear listas de varios niveles
No estoy seguro de cómo indentar código en un bloque de código
El contraste del menú desplegable de idioma para los bloques de código es un poco bajo (captura de pantalla a continuación): lo pasé por alto al principio.
La entrada de tablas como markdown no parece funcionar (cuando se ha creado una tabla en el editor antiguo, se renderiza correctamente).
Cuando una tabla va seguida de otro elemento de bloque (como una cita), no es posible insertar una nueva línea después de la tabla.
Parece que no hay soporte para notas al pie (creo que también hay un error con las notas al pie en el editor antiguo: si intento crear las notas al pie 1 y 2, solo la primera se renderiza correctamente).
Si pego una imagen del portapapeles, no estoy seguro de cómo crear texto alternativo, y tampoco sabría cómo cambiar el tamaño de la imagen.
Me gusta mucho la forma en que funcionan las listas multinivel. Simplemente comienza poniendo el markdown como de costumbre y automáticamente comienza tu primer punto. Luego presiona enter para crear el siguiente. Tab para indentar. Borrar para cambiar de viñeta a número, etc. shift-tab para crear otra viñeta.
Ok, ¡gracias! Supongo que no lo intenté por lo del bloque de código y porque no funciona en el editor antiguo. Pero tiene sentido la forma en que funciona en el nuevo editor.
Me recuerda: en realidad, sería genial si las listas numeradas ciclaran a través de diferentes símbolos (por ejemplo, primer nivel = números, segundo nivel = caracteres en minúscula, tercer nivel = números romanos, cuarto nivel = caracteres en mayúscula). Pero supongo que esto no está sobre la mesa porque no es parte de las especificaciones de CommonMark o GFM.
He usado el nuevo editor de texto unas cuantas veces recientemente y ni siquiera recordaba y noté que ahora era WYSIWYG; quiero decir con esto que me resultó tan natural usarlo que no pensé en ello mientras escribía 
como si el editor siempre hubiera sido así, aunque no lo fuera.
Ni siquiera me molestó en absoluto la estrechez de la ventana. 
Una experiencia realmente fluida, y no experimenté errores, pero mi uso fue solo contenido básico (texto, citas, formato estándar).
No sé si todavía es el caso incluso con el editor de texto normal, pero antes, la vista previa era casi 100% idéntica a la publicación definitiva. Recuerdo haberme quejado un poco hace tiempo porque el ancho de la vista previa era ligeramente diferente al ancho de una publicación, lo que hacía que la vista previa no fuera exactamente idéntica al contenido publicado.
Ahora, no estoy segura de quejarme si el editor de texto es más ancho que una publicación, si es más cómodo de usar que antes. 
¡De acuerdo, ese es un buen punto! Que el contenido publicado coincida con el contenido editado ciertamente minimizaría la fricción.
En este caso, creo que preferiría que el contenido editado estuviera en el mismo eje visual que el contenido publicado.
Bueno, este no es un medio impreso, por lo que el contenido publicado no es (casi) idéntico para todos.
Empecé a trabajar en esto ayer, espero que no sea demasiado complicado y que podamos tener algo pronto…
Ese citar en el chat no es gran cosa porque principalmente afecta a moderadores y administradores, que saben cómo volver al sistema antigo.
La función de nota al pie es más importante.
Para ser honestos, esa era solo mi opinión, y realmente no sé cómo están las cosas allá afuera.
Es gracioso. Mis usuarios estaban quejándose del markdown y la falta de WYSIWYG antes. Ahora, ninguno de ellos ha cambiado al nuevo sistema. Casi sé por qué. Casi todos usan móviles y en realidad estaban quejándose de las imágenes y no podían ver nada más que markdown.
No utilizan otra cosa, y volvemos a mi vieja afirmación: necesitamos una herramienta para ocultar y mostrar la barra de herramientas. Los usuarios habituales están acostumbrados al estilo de las redes sociales donde solo escriben texto puro, lo envían, y eso es suficiente. Y como Discourse ofrece eso, más o menos, no tienen incentivos para cambiar o probar el nuevo sistema. Excepto para ver imágenes en el creador, pero mi foro no es muy visual.
Los usuarios comunes podrían ser una historia diferente, pero no saben sobre ese mágico cambio.
