Job Three — The CMD+K Inline Diff

"Select a line, hit CMD+K, and Pippa's rewrite appears below the original — but the document doesn't change until you press Enter."

Job Three — the Inline Diff

The third job is the one that first makes Rekindle feel magic: select text, press CMD+K, and a Prompt Macro rewrites it — polished, translated, tightened — with the result landing as a Cursor-style inline diff. The original is struck in place, the proposal sits just below it, and you accept with Enter or cancel with Esc. Mechanically it's a widget decoration holding the proposal, plus a mark striking the original. When you accept, a single CM6 transaction swaps the text.

Why It's a Widget, Not an Edit-Then-Undo

The tempting shortcut is: apply the rewrite immediately, and if the user doesn't like it, let undo revert it. Rekindle refuses that, and the reason is precise: the document must not be mutated until the user accepts. The proposal is a decoration — a view layer over unchanged source — so nothing is written to the model while you're deciding. Only Enter produces an actual edit.

// The proposal is a WIDGET over unchanged source — no edit yet.
showProposal(view, { from, to, replacement });

// Only on accept does a single transaction mutate the document.
view.dispatch({ changes: { from, to, insert: replacement } });

The Autosave Trap

Here's the war story that makes 'decoration-first' non-negotiable. Rekindle autosaves on window blur. Imagine the naive flow — apply the rewrite immediately, rely on undo to cancel. You hit CMD+K, the doc changes, and then you click away to check something before deciding. Window blur fires, autosave runs, and the un-accepted rewrite is now persisted to disk. Undo can't save you; the file already changed. Because Rekindle shows the proposal as a decoration and mutates only on accept, blurring away simply dismisses it — the file is exactly what you last accepted.

CMD+K is also, quietly, a client of cwkPippa's Prompt Macro, not a new feature — Track 5 is where that reuse gets its own lesson. Here the point is the mechanism: the same decoration engine that renders bold and underlines voice issues also stages an AI rewrite, non-destructively, until you say yes.

Code

Decoration-first: mutate the document only on accept·typescript

// 1) CMD+K: call the Prompt Macro, get a rewrite, show it as a WIDGET.
//    The source is UNCHANGED — the proposal is a view-layer decoration.
function showProposal(view, { from, to, replacement }) {
  view.dispatch({ effects: setProposalEffect.of({ from, to, replacement }) });
  // strike the original (mark) + insert the proposal block (widget) — no text edit
}

// 2) Enter accepts: ONE transaction actually changes the document.
function acceptProposal(view, { from, to, replacement }) {
  view.dispatch({ changes: { from, to, insert: replacement } });
}

// 3) Esc / window-blur: just clear the decoration. Nothing was ever written,
//    so a blur-triggered autosave can't persist an un-accepted rewrite.

Exercise

Sketch the two flows for an AI rewrite preview: (A) apply the edit immediately, rely on undo to cancel; (B) show the edit as a decoration, mutate only on accept. Now add an autosave-on-blur to both and trace what's on disk if the user clicks away mid-decision. Explain in one sentence why only (B) is safe.

Hint

In (A), the blur fires between apply and decide, so autosave persists the un-accepted edit — undo is now fighting a saved file. In (B), nothing was written, so blur just dismisses the decoration; disk still holds the last accepted version.