Atomic Editor: ObsidianスタイルのライブプレビューをCodeMirror 6にもたらす
生のMarkdownとレンダリングされたプレビュー間のシームレスな切り替えは、技術ライターや開発者にとって長年の目標です。Obsidianのようなツールが「ライブプレビュー」体験—入力すると同時にフォーマットがその場でレンダリングされる—を普及させましたが、柔軟なエディタフレームワーク内でこれを実装することは依然として技術的な課題です。
Atomic Editorはkenforthewinによる新しいプロジェクトで、このパラダイムをCodeMirror 6にもたらすことを目指しています。ソースコードエディタとWYSIWYG体験の間のギャップを埋めることで、Atomic EditorはMarkdownの強力さを保ちつつ、構文マーカーの視覚的摩擦を取り除いた高忠実度の編集環境を提供しようとしています。
ライブプレビューのパラダイム
Atomic Editorの核心は「Obsidianスタイル」のライブプレビューにあります。従来のスプリットペインエディタが左側にソース、右側にレンダリングされたHTMLを表示するのとは異なり、ライブプレビューエディタは編集領域内で直接フォーマットをレンダリングします。カーソルが行やテキストブロックから離れると、Markdown構文(例えば太字の ** や見出しの #)が消え、レンダリングされたスタイルだけが残ります。カーソルがブロックに入ると、編集用に構文が再び表示されます。
このアプローチはMarkdownの「認知負荷」問題を解決しようとします。ユーザーがドキュメントの最終結果を確認しつつ、生テキストを迅速に編集できるようにするのです。
技術的実装とコミュニティのフィードバック
CodeMirror 6上にライブプレビューシステムを構築することは大規模な取り組みです。Hacker Newsでのコミュニティの反応は、現在の実装の強みと「本番品質」の体験を実現する上で残る課題の両方を浮き彫りにしています。
成功点:テーブルと仕上げの品質
複数のユーザーがプロジェクトの洗練さと特定機能の実装を称賛しました。特にテーブルの取り扱いは、プロジェクトの仕上げの品質のハイライトとして挙げられました。
テーブルに対するあなたのWYSIWYGサポートはとても素晴らしいです…テーブルの取り扱いに感心しました。仕上がりが良いプロジェクトですね。
課題:エッジケースと状態管理
どの初期段階のエディタプロジェクトでも同様に、レンダリングエンジンの「漏れやすい抽象化」が最も摩擦が生じる箇所です。ユーザーは、生テキストとレンダリングビューの同期が崩れやすい複数の領域を指摘しました:
- フェンス処理: 開始コードフェンスを削除した際に、終了フェンスが期待通りに動作しないという問題が報告されています。
- カーソルと選択: 一部のユーザーは選択ハイライトが常に正しく機能しないことを指摘し、別のユーザーは特定の状況で入力時に「ジャンプ」する挙動があると報告しています。
- インタラクションデザイン: テーブル行の削除方法やチェックボックスが編集可能なテキストに変わる方法など、小さなUXの詳細が改善の余地として残っています。
アーキテクチャ上の議論:CodeMirror vs. ProseMirror
コミュニティが提起した興味深い技術的議論の一つは、基盤となるエディタエンジンの選択です。ある貢献者は、後者が一般的に散文やリッチテキスト編集向けであるにもかかわらず、なぜプロジェクトがProseMirrorではなくCodeMirrorを選んだのか質問しました。
この選択は重要です。CodeMirror 6はまずテキストエディタとして設計されており、大規模ファイルでも高いパフォーマンスを発揮し、生テキストの操作に優れています。一方、ProseMirrorは構造化ドキュメントエディタです。CodeMirror上に構築することで、Atomic Editorはユーザーがコードエディタのような感覚でありながらドキュメントのように見えるツールを好むと見込んでいます。Markdownをサポートするワードプロセッサ的なツールではなく、ということです。
結論
Atomic EditorはMarkdown編集体験を近代化しようとする野心的な試みです。依然として初期段階のソフトウェアに特有の問題—特にカーソル移動の精度や複雑なMarkdownブロックの取り扱い—に直面していますが、オープンソースのリッチテキスト編集の未来を示す説得力のあるビジョンを提供します。このパラダイムの独自実装に苦労した人々にとって、Atomic Editorは本番環境向けのライブプレビューエディタの有望な基盤を提供します。