Why CM6 Wins

"The decoration engine doing triple duty isn't a nice bonus. It's the whole reason CodeMirror was chosen."

Three Features, One Primitive

Step back and look at the three jobs together. Live Preview: compute ranges, attach marks. Voice underline: compute ranges, attach marks and a widget. CMD+K: attach a widget holding a proposal, mutate on accept. Three features that look completely unrelated — a renderer, a linter, an AI editor — collapse to the same shape: compute ranges over the source, attach decorations, mutate only when the user commits. One primitive, learned once, powering the entire soul layer.

Live Preview   ranges -> marks                       (render the look)
Voice underline ranges -> marks + a margin widget      (flag voice issues)
CMD+K          a widget proposal -> one accept edit    (stage an AI rewrite)

# Different inputs. Same decoration primitive. That's the win.

Why a Rich-Text Model Would Fork Into Three Detours

Now imagine building the same three features on a rich-text tree (Tiptap/Lexical). Live Preview isn't even a concept — the tree is the rendered form, so "show source with a rendered look" fights the model. The voice underline has to find and annotate positions in a node tree instead of character ranges. The CMD+K preview has to represent a non-destructive proposal inside a document model that wants to be edited directly. Each feature becomes its own detour against the tree's grain. You'd build three subsystems, not one.

The Reuse Is the Architecture

This is why 'one mechanism, three jobs' is a load-bearing decision, not a happy accident. CodeMirror was chosen because its decoration-over-source primitive makes all three soul features the same shape. The whole product — margin-Pippa, live voice, inline AI — rides one mechanism you build and debug once. That's the family's first pillar, Reuse, expressed as an editor-core choice: don't pick the substrate with the most features; pick the one whose single primitive your features already share. When the reuse is that deep, it stops being an optimization and becomes the architecture.

Code

Three jobs, one decoration primitive·text

Feature         Shape                                   Kind
--------------  --------------------------------------  -----------------
Live Preview    ranges -> marks                         render the look
Voice underline ranges -> marks + a margin widget       flag voice issues
CMD+K           a widget proposal -> one accept edit    stage an AI rewrite

# Different inputs, same primitive. In a rich-text tree, each of these
# would be a separate detour against the document model. CM6 makes them one.

Exercise

Take any editor feature you'd want to add to Rekindle next (say, showing translation suggestions, or highlighting repeated words). Ask: does it reduce to 'compute ranges over source, attach marks or a widget, mutate on accept'? If yes, it's nearly free — it rides the existing engine. Notice how the substrate choice keeps paying off with every new feature.

Hint

Most 'show something over the writer's text' features do reduce to the decoration shape. The ones that don't (a true rich-text table editor, say) are exactly the features that would justify a different substrate — which is how you'd know Rekindle had outgrown its core, if it ever did.