Composer: clique/seleção na prévia deve revelar/selecionar a fonte Markdown correspondente (especialmente matemática)

Problema / motivação

Ao editar publicações com muitas fórmulas matemáticas, muitas vezes é difícil localizar a fonte exata de uma equação renderizada no editor de Markdown.

Em publicações longas com muitas expressões em linha com \$...\$ ou múltiplos blocos de exibição com \$\$...\$\$, o fluxo de trabalho se torna:

detectar um erro na pré-visualização → procurar manualmente no Markdown bruto → ajustar → verificar novamente a pré-visualização

Isso é especialmente problemático para pequenas edições (sinal de menos ausente, índice incorreto, ajuste de espaçamento, etc.) e piora à medida que as publicações crescem.

Comportamento proposto

No editor:

  • Clicar ou selecionar um elemento renderizado no painel de pré-visualização deve:
  • rolar o editor de Markdown bruto para a origem correspondente, e
  • colocar o cursor dentro (ou selecionar) o texto de origem que o produziu.

Isso funcionaria particularmente bem para:
• Matemática ($...$, $$...$$)
• Citações
• Listas
• Links
• Outros elementos processados

A matemática é o caso de uso mais convincente, mas o comportamento seria amplamente útil.

Por que isso é diferente da sincronização de rolagem

Não se trata de rolagem sincronizada enquanto se digita.

É um salto da pré-visualização para a origem, semelhante em espírito ao SyncTeX em editores LaTeX:

“Estou olhando para esta coisa renderizada - mostre-me de onde ela veio.”

Direção de implementação possível (visão geral)

Durante o processamento, os nós de saída poderiam carregar metadados leves de mapeamento de origem (por exemplo, data-sourcepos="start:end" ou similar).

Na pré-visualização do editor:

  • Ao clicar/selecionar, percorrer o DOM até o nó mais próximo com metadados de posição de origem.
  • Usar a API existente do editor para definir o intervalo de seleção no editor bruto e rolá-lo para a visualização.

Esse tipo de mapeamento de origem já existe conceitualmente em ferramentas CommonMark, e os blocos de matemática em particular são candidatos naturais, pois já são tokenizados de forma distinta.

Por que isso seria valioso

  • Iteração muito mais rápida em conteúdo com muitas fórmulas matemáticas
  • Reduz a carga cognitiva ao editar publicações técnicas longas
  • Torna o painel de pré-visualização genuinamente interativo, não apenas passivo
  • Escala bem para outros elementos processados além da matemática

Fico feliz em preparar um GIF curto se isso ajudar a ilustrar a interação.

1 curtida