Esta es una idea interesante, el objetivo sería tener resaltado de sintaxis en el textarea (es decir, el lado izquierdo del compositor) para que puedas ver si estás cometiendo algún error de sintaxis markdown. Sí, los bloques de código hacen lo mismo en la vista previa, pero no verás ningún error de markdown, por ejemplo. Y algunos markdown complejos serían más fáciles de escanear, como publicaciones con muchas tablas, cargas, enlaces, encabezados.
Sin embargo, no estoy seguro de que sea fácil hacer esto. Nuestras pantallas de administración utilizan el Editor ACE, y no creo que podamos simplemente arrastrar y soltar eso en el compositor de publicaciones.
Proporciona una retroalimentación muy directa sobre tu sintaxis: no tienes que mirar al panel derecho cada dos segundos para comprobar si no estás cometiendo errores de sintaxis triviales.
Daría un poco más de estructura a aquellos que son menos aptos en Markdown (cualquier principiante).
Por supuesto, todavía tienes el HTML renderizado en el lado derecho de la ventana del compositor.
No vería ninguna desventaja inmediata en esto, especialmente si es una opción.
PD: Aparentemente, ni siquiera hay un resaltador de sintaxis de Markdown instalado para los bloques de código :
# La sintaxis de los bloques de código Markdown...
... desafortunadamente ...
- no está
- resaltada
**en absoluto**!
Sin embargo, podría imaginar que el Milkdown más simple sería más adecuado, ya que no pasa nada si el editor da una sensación más de ‘pantalla submarina’[1], ya que de todos modos tienes la vista previa a la derecha.
Sí, cualquiera de ACE, TUI, Milkdown supondría un cambio muy grande, todos necesitarían reemplazar el textarea por contenteditable. Vale la pena experimentarlo, sin duda, pero en el núcleo es un proyecto grande.
Para ampliar, primero, esto es algo que realmente quiero que el núcleo de Discourse admita, pero también vale la pena ampliar la complejidad.
El núcleo de Discourse utiliza muchas, muchas API directamente contra TEXTAREA, @menciones, el editor inserta cosas en TEXTAREA, cargas, cortar y pegar imágenes y más.
Todo esto no está abstraído y asume que está hablando con un TEXTAREA. Agregar un contenteditable allí directamente significaría que también necesitaría simular un TEXTAREA de manera adecuada y muy precisa, algo que probablemente fallará. Necesitamos una cantidad considerable de trabajo para crear algún tipo de marco de proveedor para poder intercambiar cosas.
Ver también:
Highlighter es ciertamente un gran primer paso en esta dirección, ya que no tienes que preocuparte por el mapeo bidireccional de markdown a texto.
Puede haber algún truco ninja donde puedas ocultar el TEXTAREA y luego renderizar un contenteditable encima de él, transfiriendo eventos al original, pero incluso eso requeriría una reimplementación del posicionamiento de @mención.
Personalmente, no me gusta. Está demasiado abarrotado. Me encanta que el editor en Discourse sea visualmente limpio. Todo lo que realmente veo es texto, y lo renderizado está a un lado, donde pertenece.
Volviendo al punto principal del resaltado de sintaxis, esto es algo que también me encantaría ver. Como mínimo, me encantaría que los # Encabezados y ## Subencabezados se resaltaran de alguna manera. No puedo decirte cuántas veces busco en mis publicaciones más largas, donde la vista previa y el editor están desalineados, y me lleva una eternidad encontrar mi # encabezado relacionado.
Para mí, simplemente hacer que los # Encabezados estén en negrita, o en un color particular en el lado del editor del compositor, sería una mejora masiva.
Esto es muy bueno de escuchar: usar markdown es genial para nuestros usuarios avanzados, pero supone una curva de aprendizaje bastante pronunciada para la mayoría de nuestros usuarios menos avanzados y contribuiría en gran medida a hacer nuestra comunidad más accesible.
Hola @lindsey, no quiero apresurarte de ninguna manera, pero pensé que podría preguntar si pudiste compartir lo siguiente:
Si los cambios incluirán interoperabilidad / un marco para permitir que los complementos desarrollen soluciones de editor.
Relacionado con esto, si estás considerando desarrollar tu propio editor de texto enriquecido, por ejemplo, en un complemento.
Una idea aproximada del cronograma que estás considerando para 1 y / o 2.
El contexto para mí es el enfoque y el cronograma de este proyecto potencial
@Rohail_Altaf y yo estamos intentando pensar en la mejor manera de abordar esto, particularmente en cuanto al cronograma. Sin embargo, entiendo perfectamente si no puedes compartirlo en esta etapa.
Hola Angus. Disculpa la demora, ¡estuvimos en el retiro anual de nuestra empresa en Tokio!
No puedo darte demasiados detalles en este momento, ya que todavía estamos definiendo los detalles de implementación. Creo que tendremos eso resuelto en las próximas semanas, al menos lo suficiente como para responder a estas preguntas, así que volveré a contactarte una vez que sepamos más.
Discourse ahora está enviando un editor experimental WYSIWYG
Esta infraestructura también hace posible a largo plazo aplicar resaltado de sintaxis en markdown si queremos seguir ese camino, aunque se vuelve mucho menos necesario con el nuevo editor.
Por ejemplo, ¡el nuevo editor ahora te permite aplicar resaltado de sintaxis al código mientras lo escribes!