Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

diff: add a true in-place "inline" overlay (virtual text) as the future layout = "inline"

Open
  • Is something wrong?
#294 1 comment 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
lua, neovim
Domain
devtools

Research direction

Start by tracing the current layout = "unified" path and comparing it with the native diff behavior referenced in #293, #195, #169, #277, and #205. Define the single-buffer extmark view, editable added lines, virtual deleted lines, accept/reject behavior, and ClaudeCodeDiffOpened / ClaudeCodeDiffClosed autocmd handling; done means the proposed inline mode works without an extra window and preserves review edits.

Written by the indexing model from the issue text.

Description

triage:done

Summary

Follow-up to #293 / #195. The diff_opts.layout = "unified" option (renamed from "inline" before v0.4.0) renders a unified diff in a separate vsplit pane — a single read-only buffer with interleaved red/green lines. This issue tracks adding a true in-place inline overlay: the diff shown as virtual text layered onto the file in the same window, the way users typically picture a "VS Code-style inline" diff (cf. mini.diff, gitsigns preview, sidekick NES, Cursor inline edits).

When implemented, this mode is the one that should claim layout = "inline" — which is exactly why we reserved that name in #293.

"unified" vs the proposed "inline"

  • "unified" (shipped): single read-only buffer in a rightbelow vsplit, deleted (red/strikethrough) + added (green) lines interleaved. Compact, but it's a separate pane and not editable before accept.
  • "inline" (this issue): no extra window — proposed changes rendered in place over the real file.

Suggested approach (keeps pre-accept editability)

The unified/read-only path forfeits editing the proposal before accepting. A prototype pattern that keeps it (the codecompanion/sidekick model):

  • Proposed/added lines = real, editable buffer lines, highlighted (e.g. ClaudeCodeInlineDiffAdd) with a + sign.
  • Deleted lines = virtual text via nvim_buf_set_extmark virt_lines (strikethrough/red), so they're visible but not part of the editable content.
  • On accept, the buffer content already is the new file (deleted lines were never real text), so edits made during review are captured. On reject, clear the extmarks / restore.

A pure-Lua, zero-dependency engine (not mini.diff/diffview — see #169) keeps this aligned with the project's philosophy. Bonus: a single-buffer extmark view sets no &diff windows, which sidesteps the closeAllDiffTabs foreign-diff class (#277) and the stale-diff repaint issues (#205).

Notes

  • The current "unified" path doesn't fire the ClaudeCodeDiffOpened / ClaudeCodeDiffClosed User autocmds that the native diff does — worth wiring up for any new mode.
  • @wookayin expressed interest ("once we implement that") on #195 — collaboration welcome.

Refs #293, #195, #82

🤖 Generated with Claude Code

Dominant language
Lua
Stars
3.1k
Forks
219
No merged PRs in 30d

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from coder/claudecode.nvim

All issues in coder/claudecode.nvim

Similar issues

More Lua issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.