[zhao-tong]

Summary

Add a new layout = "inline" option for diff_opts that renders a VS Code-style unified inline diff - a single read-only buffer with deleted (red/strikethrough) and added (green) lines interleaved. This complements the existing "vertical" and "horizontal" two-panel diff layouts.

Closes #82

Motivation

The existing diff layouts use Neovim's built-in diffthis to show old and new content side by side. While effective, this uses significant screen real estate with two panels. An inline unified diff provides a more compact view that's familiar to VS
Code users, showing changes in context within a single buffer.

Changes

• New module lua/claudecode/diff_inline.lua — self-contained inline diff implementation with:
  • Pure diff computation via vim.diff() (indices mode)
  • Extmark-based rendering with sign column markers (+/-)
  • Resolution (accept/reject) and cleanup functions
• Dispatch in diff.lua — routes to inline module when layout = "inline" is configured; exposes shared utilities as M._ members following existing patterns
• Config/types — validates "inline" as a valid layout value
• close_all_diff_tabs — detects inline diff buffers via claudecode_inline_diff buffer variable
• Test mock — adds vim.diff mock with LCS-based hunk computation to tests/mocks/vim.lua
• 23 new tests covering diff computation, content extraction, rendering, MCP response format, config validation, and cleanup

Configuration

require("claudecode").setup({
  diff_opts = {
    layout = "inline", -- "vertical" (default), "horizontal", or "inline"
  },
})

Highlight groups are customizable:

• ClaudeCodeInlineDiffAdd — green background for added lines
• ClaudeCodeInlineDiffDelete — red background + strikethrough for deleted lines
• ClaudeCodeInlineDiffAddSign / ClaudeCodeInlineDiffDeleteSign — sign column colors

Requirements

• layout = "inline" requires Neovim >= 0.9.0 (for vim.diff())
• The plugin's base requirement remains Neovim >= 0.8.0; only inline layout needs 0.9+

Design Decisions

1. Separate module rather than inlining into diff.lua — keeps the already-large file manageable; inline diff uses fundamentally different rendering (extmarks vs diffthis)
2. layout field in diff state — enables dispatch in resolution/cleanup without re-reading config
3. Read-only buffer — inline diff is review-only; content extraction uses saved line_types array rather than parsing buffer text
4. Always vsplit — single buffer doesn't need horizontal/vertical choice

Test Plan

• luacheck lua/ tests/ passes with 0 warnings / 0 errors
• All 406 tests pass (23 new, 5 pre-existing failures unrelated to this change)
• Manual: layout = "inline" → single-window diff with colored lines
• Manual: Accept (aa) → file saved correctly, diff closes
• Manual: Deny (ad) → file unchanged, diff closes
• Manual: New file creation → all lines shown as green/added
• Manual: layout = "vertical" still works unchanged (regression check)

[CortlandMorse]

Bumping ➕ , this is a feature I'd love as well.

[joshualawson]

+1 need this!

[RitvarsZvejnieksApplyIT]

+1

[wookayin]

Nice feature! However it still opens a new ...(inline diff). VS Code like inline unified diff would mean showing inline diff in virtual text using extmarks, in the same window rather than vsplit.

Also let's beware of potential breaking changes in the layout options, as this sounds more like "inline_vertical" (or "vertical_inline") whereas the true overlay+extmarks mode (once we implement that) should deserve "inline".

[ThomasK33]

Thanks @wookayin — you're right on both counts. The shipped layout = "inline" is a unified diff in a separate rightbelow vsplit, not an in-place virtual-text overlay, and shipping it under the name "inline" would have boxed us into a breaking rename once the real overlay lands.

Since it hasn't gone out in a tagged release yet, we're renaming it now: layout = "inline" → "unified" in #295, which reserves "inline" for the true in-place overlay. The naming rationale is in #293.

I opened #294 to track that real overlay — the prototype direction is proposed lines as real, editable text + deleted lines as virt_lines extmarks, so the proposal stays editable before accept (the codecompanion/sidekick model). You said "once we implement that" — would genuinely welcome your input or a hand on it if you're up for it. 🙏