Composer: プレビューでのクリック/選択は、対応するMarkdownソース(特に数式)を表示/選択すべき

問題 / 動機

数式が多い投稿を編集する際、Markdownコンポーザー内のレンダリングされた数式の正確なソースを見つけるのが難しいことがよくあります。

多くのインラインの\$...\$式や複数の\$\$...\$\$表示ブロックを含む長い投稿では、ワークフローは次のようになります。

プレビューで間違いを見つける → 生のMarkdownを手動で探す → 調整する → プレビューを再確認する

これは、小さな編集(マイナス記号の欠落、誤ったインデックス、間隔の微調整など)の場合に特に面倒であり、投稿が長くなるにつれて悪化します。

提案される動作

コンポーザー内で:

  • プレビューペイン内のレンダリングされた要素をクリックまたはハイライトすると、次のことが行われるべきです。
  • 対応するソースに生のMarkdownエディターをスクロールし、
  • キャレットを生成したソーステキスト内(またはそのテキストを選択)に配置する。

これは特に次の場合にうまく機能します。
• 数式($...$, $$...$$
• 引用
• リスト
• リンク
• その他の処理済み要素

数式が最も説得力のあるユースケースですが、この動作は広範囲にわたって役立ちます。

スクロール同期と異なる点

これは、入力中のスクロール同期に関するものではありません。

これは、LaTeXエディターのSyncTeXと精神的に類似した、プレビューからソースへのジャンプです。

「このレンダリングされたものを見ている - それがどこから来たのかを示してほしい。」

考えられる実装の方向性(概要)

処理中に、出力ノードは軽量なソースマッピングメタデータ(例:data-sourcepos="start:end"など)を保持できます。

コンポーザープレビューで:

  • クリック/選択時に、ソース位置メタデータを持つ最も近いノードまでDOMを遡ります。
  • 既存のコンポーザーAPIを使用して、生の編集領域の選択範囲を設定し、ビューポートにスクロールします。

このようなソースマッピングは、CommonMarkのツールでは概念的にすでに存在しており、数式ブロックは、すでに個別にトークン化されているため、特に自然な候補となります。

なぜこれが価値があるのか

  • 数式が多いコンテンツのイテレーションが大幅に高速化する
  • 長い技術的な投稿を編集する際の認知的負荷を軽減する
  • プレビューペインを単なる受動的なものではなく、真にインタラクティブなものにする
  • 数式以外の処理済み要素にもうまくスケールする

やり取りを説明するのに役立つ短いGIFを作成することも可能です。

「いいね!」 1