diff: reconsider `layout = "inline"` naming before v0.4.0 (reserve "inline" for a true in-place overlay)

[ThomasK33]

Summary

PR #195 added diff_opts.layout = "inline" (merged in f64c307, queued for v0.4.0 via release-please #279). @wookayin pointed out that the shipped implementation isn't a true "inline" diff in the VS Code sense, and that the name risks a breaking-change trap later. This issue tracks deciding the naming before v0.4.0 ships, while it's still cheap to change.

What layout = "inline" does today

It renders a unified diff in a separate vsplit pane — a single read-only buffer named <file> (inline diff) with interleaved red (deleted) / green (added) lines:

• lua/claudecode/diff_inline.lua:260 → rightbelow vsplit (opens a new window)
• lua/claudecode/diff_inline.lua:200 → buffer named … (inline diff)
• lua/claudecode/diff_inline.lua:206 → modifiable = false

The concern

A "VS Code-style inline" diff, as users typically picture it, is an in-place overlay: changes shown as virtual text (virt_lines extmarks) layered onto the file in the same window, not a separate split (cf. mini.diff, gitsigns preview, sidekick NES, Cursor inline edits).

So:

1. The shipped "inline" is really "a unified diff in a vertical split" — closer to "unified" / "inline_vertical" than to true inline.
2. If/when we add the real in-place overlay, that mode is the one that most deserves the name "inline". Shipping the current behavior as "inline" now forces a later choice between an awkward name for the overlay or a breaking rename of "inline".

Why now

"inline" is not yet in a tagged release (latest is v0.3.0), but it is queued in the open release-please PR #279 (v0.4.0). Renaming is free before that PR merges and a breaking change afterward.

Options

1. Rename now, reserve "inline" for the overlay — e.g. "unified" (canonical diff term, orthogonal to vertical/horizontal). Optionally keep "inline" as a deprecated, warned alias for users tracking main. (Recommended.)
2. Keep "inline", name the future overlay "overlay" / "in_place". Defensible — VS Code's diff editor does have an "Inline View" toggle (renderSideBySide=false) that produces exactly this unified single-pane view.
3. Status quo — accept the future naming cost.

Rename surface (if we rename)

• lua/claudecode/config.lua:132-137 — validation + error message
• lua/claudecode/types.lua:34 — ClaudeCodeDiffLayout alias
• lua/claudecode/diff.lua — dispatch checks at lines 834 / 928 / 1157 / 1306 (the internal claudecode_inline_diff buffer var at :1780 can stay)
• lua/claudecode/diff_inline.lua — module + buffer name
• README.md:374-378
• tests/unit/diff_inline_spec.lua
• release-please PR chore(release): 0.4.0 #279 changelog entry

Related / out of scope here

• Original feature request: [FEATURE] Inline diff #82
• Source feedback: feat(diff): add layout = "inline" for VS Code-style unified diff #195 (comment)
• Separate follow-ups (not naming): the inline path is read-only (no pre-accept editing); it doesn't fire the ClaudeCodeDiffOpened / ClaudeCodeDiffClosed autocmds the native diff does; README "VS Code-style" wording oversells it. A true in-place overlay (proposed = real editable lines, deleted = virt_lines) is the likely future "inline".