Problema / motivación
Al editar publicaciones con mucho contenido matemático, a menudo es difícil localizar la fuente exacta de una ecuación renderizada en el editor de Markdown.
En publicaciones largas con muchas expresiones en línea de \$...\$ o múltiples bloques de visualización de \$\$...\$\$, el flujo de trabajo se convierte en:
detectar un error en la vista previa → buscar manualmente en el Markdown sin procesar → ajustar → volver a comprobar la vista previa
Esto es especialmente molesto para ediciones pequeñas (falta un signo menos, un índice incorrecto, un ajuste de espaciado, etc.), y empeora a medida que las publicaciones crecen.
Comportamiento propuesto
En el editor:
- Hacer clic o seleccionar un elemento renderizado en el panel de vista previa debería:
- desplazar el editor de Markdown sin procesar a la fuente correspondiente, y
- colocar el cursor dentro (o seleccionar) el texto fuente que lo produjo.
Esto funcionaría especialmente bien para:
• Matemáticas (\$...\$, \$\$...\$\$)
• Citas
• Listas
• Enlaces
• Otros elementos procesados
Las matemáticas son el caso de uso más convincente, pero el comportamiento sería útil en general.
Por qué esto es distinto de la sincronización de desplazamiento
No se trata de la sincronización del desplazamiento mientras se escribe.
Es un salto de vista previa → fuente, similar en espíritu a SyncTeX en los editores LaTeX:
“Estoy viendo este elemento renderizado; muéstrame de dónde vino.”
Posible dirección de implementación (a alto nivel)
Durante el procesamiento, los nodos de salida podrían llevar metadatos ligeros de mapeo de origen (por ejemplo, data-sourcepos="inicio:fin" o similar).
En la vista previa del editor:
- Al hacer clic/seleccionar, recorrer el DOM hasta el nodo más cercano con metadatos de posición de origen.
- Usar la API existente del editor para establecer el rango de selección en el editor sin procesar y desplazarlo a la vista.
Este tipo de mapeo de origen ya existe conceptualmente en las herramientas de CommonMark, y los bloques matemáticos en particular son candidatos naturales ya que ya están tokenizados de forma distinta.
Por qué sería valioso
- Iteración mucho más rápida en contenido con mucho contenido matemático
- Reduce la carga cognitiva al editar publicaciones técnicas largas
- Hace que el panel de vista previa sea genuinamente interactivo, no solo pasivo
- Escala bien a otros elementos procesados más allá de las matemáticas
Estaré encantado de preparar un GIF corto si eso ayuda a ilustrar la interacción.