Skip to content

Design seamless inline Markdown source projection #44

Description

@Azganoth

Summary

Design the implementation model for seamless inline Markdown source projection.

Leafdown currently exposes active inline/source Markdown through separate input widgets. The desired long-term behavior is to reveal Markdown markers directly in the editor surface so the caret can move through marker characters and editing those characters updates document semantics.

Before implementation, decide which ProseMirror/Milkdown architecture can support this without brittle keyboard hacks or data-loss edge cases.

Questions to answer

  • Should inline source projection temporarily transform the editor document into editable source text while focused?
  • Can this be implemented safely with ProseMirror decorations/widgets, or are decorations insufficient because projected marker text must be truly editable?
  • How should projection entry and exit interact with history, undo/redo, dirty-state tracking, and serialization?
  • What happens when projected syntax becomes invalid or partially edited?
  • How should caret positions map between rendered content and projected source text?
  • Should links, autolinks, footnote references, raw HTML, and images use the same model as strong/emphasis/inline code?
  • What is the smallest safe first implementation slice?

Candidate approaches to evaluate

  1. Temporary source-projection mode:
    Replace the active inline range with editable source text while focused, then parse it back into the rich document model on exit.

  2. Decoration-driven projection:
    Use inline/widget decorations to display markers and intercept editing behavior.

  3. Schema/model extension:
    Represent editable marker syntax explicitly in the editor model.

  4. Keep separate source inputs:
    Document why the current approach should remain if the seamless model is too risky.

Expected output

  • Recommended architecture.
  • Rejected alternatives with reasons.
  • First implementation slice.
  • Edge cases that must be tested.
  • Required docs/spec updates.

Done when

  • A preferred implementation strategy is chosen.
  • The strategy accounts for caret movement, deletion, undo/redo, dirty state, and serialization.
  • Strong/emphasis partial-marker editing is explicitly addressed.
  • Link/autolink/footnote/raw HTML behavior is scoped.
  • Follow-up implementation issue is created with concrete acceptance criteria.

Metadata

Metadata

Assignees

Labels

SpikeInvestigation needed before committing to implementation

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions