Feature : Better diff view

i also want this

Planned / In progress features #43 (comment)

sth like

We can look into this together; I want our code to have sufficient flexibility and maintainability.

The core code itself should contain as little code as possible, offloading reasonable complexity to our own nvim configuration.

It is indeed an interesting concept.

However this can add a lot of complexity.

There is already a possibility to view the diffs in a session, which uses the snapshots feature of opencode. But it's a but clunky at the moment, and I don't use it that much.

For the planning plugin, it's also an interesting idea, I remember seeing a video by the opencode creator on a special flag with a similar workflow for plans, but I haven't checked if it was ever implemented properly.

https://x.com/thdxr/status/2011204789607284974

I used plannotator as an example because their recent versions also support code review functionality. I believe that if it's just about the features, an LLM should be able to generate them quite easily. They only need to research how these two frameworks achieved it and migrate it over. We could even consider reusing the diffview plugin.

After all, there's really no difference—it's just about popping up an interface where we can happily comment on things in the nvim style, then package and send it. The code view and plan are the same

But the key here, I think, is how to do it. Opencode has various plugins, and TUI will likely also introduce various plugins soon. As you mentioned in another comment, our core code should be as concise as possible.

In my experience, the plan mode of opencode has always been the weaker one compared to claude code and codex... although I am aware of and have enabled the environment variable.

Agreed, the complexity concern is real. Looking at the codebase, the problem isn't really implementing the diff review UI itself — it's that there's no clean place to put it.

What makes this hard right now: (Sorry , I need AI to help me express the following statement)

api.lua is a 1593-line catch-all: every command, slash command, and routing logic lives here. Adding diffview integration or plan mode means touching command registration, business logic, and slash command mapping all in the same file — there's no natural boundary to work within.
state.lua (614 lines) is a god object: 30+ fields covering UI, session, server, and context all mixed together, plus UI decision logic that arguably shouldn't be in a state container at all (TOGGLE_ACTION_RULES, STATUS_DETECTION, hidden buffer normalization...). Any new tool that needs its own state — review session, plan steps, file tree — either piles onto this or manages state separately and loses the existing subscribe mechanism.
Core isn't feature-agnostic: core.lua / api.lua have feature-specific logic baked in — diff functions, markdown renderer detection (RenderMarkdown/Markview), footer mode hardcoded to only recognize build/plan. Policy is tangled with mechanism, so adding anything new means touching code that was never meant to be touched for that purpose.

What good separation would actually unlock(It also consumes a significant amount of time)

Taking diff review + comment feedback as a concrete example: CLI produces changes → nvim shows diff → user reviews and writes comments → collect → format → send back. The core really only needs to own two things here:

A structured interface for change data — right now snapshot.lua is tied to shadow git and just gives you a raw file list. Something like {file, hunks, before, after} that works regardless of whether the source is a snapshot, buffer diff, or CLI plan output.
A channel to send structured feedback back to the CLI — not just a raw text message, but something with file/line/comment type attached.
Everything else — whether to use diffview or vim diff, how to collect comments, how to format them for the LLM — that's all policy. It can live in an extension or recipe without touching core. Which means different users can wire up their own review workflow, and contributors can improve the review experience without needing to understand the whole plugin first.

The most idealistic approach would still be to clean up the code, refactoring it to the point where any subsequent feature additions require minimal changes. However, this would entail a lengthy refactoring period (even with AI assistance, it means we cannot meticulously review the details of each modification), during which there would be no obvious improvements in user experience.

I originally thought I had some time, but the sheer volume of potential changes is indeed a bit overwhelming.

But I'm still willing to push forward with code clean and feat impr, or rather, if you don't have much time, I might do it myself (I still prefer to contribute code to you), but I'm not sure if we need some other conveniences in terms of collaboration... At the very least, the refactoring should be on a separate branch, so that when we push code it can be relatively more convenient...

I think a good strategy would be one branch per "change"

if we refactor api, this should be a branch. I tend to like smaller more focused branches as it's faster and a lot less rebasing.
Because main will still move and at one point it will become almost impossible to keep them in sync (I've been burned by this multiple times at work)

I agree with most of the refactor proposed as I concluded the mostly the same.

There is already a state refactoring that I started.

I will create an issue for the refactoring as this is not related to the diff view

@jensenojs

@jensenojs
For inspiration, I saw this plugin this morning
https://github.com/MaraniMatias/codereview.nvim

Maybe we could make this plugin more "extensible" and have this kind of feature in a dedicated plugin.

@sudo-tee

@sudo-tee
I will keep it in mind and refer to it, but I'm still struggling with the split of api.lua (I hope to clean up the execution chain, commands + hooks, and other related things behind the scenes. Maybe I'll try to draft something in the next day or two).

The issues and pull requests on opencode have become practically unmanageable. I hope our project can become that popular too,, but it's best to avoid that kind of chaos 🤣.

Additionally, a possibly unrelated but personally very interesting direction is the integration with another plugin

But there is still a long way to go with code cleanup, I hope to achieve this flexibility as much as possible through recipes, ideally with the help of AI to make it happen

Agreed, the complexity concern is real. Looking at the codebase, the problem isn't really implementing the diff review UI itself — it's that there's no clean place to put it.同意，复杂性问题确实存在。看代码库，问题其实不在于实现差异审查界面本身——而是没有一个干净的地方放置它。

What makes this hard right now: (Sorry , I need AI to help me express the following statement)现在让这件事变得困难的原因：（抱歉，我需要 AI 帮我表达以下陈述）

api.lua is a 1593-line catch-all: every command, slash command, and routing logic lives here. Adding diffview integration or plan mode means touching command registration, business logic, and slash command mapping all in the same file — there's no natural boundary to work within.api.lua 是一个包含 1593 行的万用代码：每个命令、斜杠命令和路由逻辑都存在于此。添加 diffview 集成或计划模式意味着要在同一文件中处理命令注册、业务逻辑和斜击命令映射——没有自然的界限可支配。

state.lua (614 lines) is a god object: 30+ fields covering UI, session, server, and context all mixed together, plus UI decision logic that arguably shouldn't be in a state container at all (TOGGLE_ACTION_RULES, STATUS_DETECTION, hidden buffer normalization...). Any new tool that needs its own state — review session, plan steps, file tree — either piles onto this or manages state separately and loses the existing subscribe mechanism.state.lua（614 行）是一个神对象：30+字段涵盖 UI、会话、服务器和上下文，混合在一起，还有 UI 决策逻辑，这些逻辑本不该存在状态容器（TOGGLE_ACTION_RULES、STATUS_DETECTION、隐藏缓冲区规范化......）。任何需要独立状态的新工具——如审查会话、规划步骤、文件树——要么叠加到这些工具上，要么单独管理状态，失去现有的订阅机制。

Core isn't feature-agnostic: core.lua / api.lua have feature-specific logic baked in — diff functions, markdown renderer detection (RenderMarkdown/Markview), footer mode hardcoded to only recognize build/plan. Policy is tangled with mechanism, so adding anything new means touching code that was never meant to be touched for that purpose.Core 并非功能中立：core.lua / api.lua 内置了功能专属逻辑——diff 函数、markdown 渲染器检测（RenderMarkdown/Markview）、硬编码的页脚模式只识别构建/规划。政策与机制纠缠在一起，所以添加任何新内容就意味着触及那些本不该为此目的而动的代码。

What good separation would actually unlock(It also consumes a significant amount of time)什么样的分离会解锁（而且会消耗大量时间）

Taking diff review + comment feedback as a concrete example: CLI produces changes → nvim shows diff → user reviews and writes comments → collect → format → send back. The core really only needs to own two things here:以差异审查+评论反馈为具体例子：CLI 生成变更，→NVIM 显示用户评论的差异→并撰写评论，收集格式→收集→→反馈。核心实际上只需要拥有两样东西：

A structured interface for change data — right now snapshot.lua is tied to shadow git and just gives you a raw file list. Something like {file, hunks, before, after} that works regardless of whether the source is a snapshot, buffer diff, or CLI plan output.一个结构化的变更数据接口——目前 snapshot.lua 绑定在 shadow git 上，只给你一个原始文件列表。比如{file， hunks， before， after}，无论源是快照、缓冲区差值还是 CLI 计划输出都能正常使用。

A channel to send structured feedback back to the CLI — not just a raw text message, but something with file/line/comment type attached.一个通道，用来向 CLI 发送结构化反馈——不仅仅是原始文本消息，而是带有文件/行/注释类型的内容。
Everything else — whether to use diffview or vim diff, how to collect comments, how to format them for the LLM — that's all policy. It can live in an extension or recipe without touching core. Which means different users can wire up their own review workflow, and contributors can improve the review experience without needing to understand the whole plugin first.其他的——用 diffview 还是 vim diff，如何收集评论，如何格式化 LLM——这些都是政策。它可以存在于扩展或配方中，而不涉及核心。这意味着不同的用户可以自行布线评审工作流程，贡献者无需先了解整个插件，也能提升评审体验。

Recently, another codediff plugin has also become quite popular, and neogit now supports both codediff and diffview as diff backends.
https://github.com/esmuellert/codediff.nvim

some kind of poc

opencode.commands.register("/hunk-review", {
  description = "Review git hunks one by one",
  execute = function()
    local hunks = opencode.context.git_hunks()        -- 1
    for _, hunk in ipairs(hunks) do
      local prompt = opencode.context.format({
        text = "Review this hunk:\n" .. hunk.diff,
        file = hunk.file,
      })
      local response = opencode.messaging.send_and_wait(prompt)   -- 2
      local action = opencode.ui.popup({                          -- 3
        content = response.text,
        title = hunk.file .. ":" .. hunk.line,
        actions = { "approve", "comment", "skip" },
      })
      if action == "comment" then
        -- user writing some comment here, or some small model predict what user want to say
      end
    end
  end,
})

some kind of poc

opencode.commands.register("/hunk-review", {
  description = "Review git hunks one by one",
  execute = function()
    local hunks = opencode.context.git_hunks()        -- 1
    for _, hunk in ipairs(hunks) do
      local prompt = opencode.context.format({
        text = "Review this hunk:\n" .. hunk.diff,
        file = hunk.file,
      })
      local response = opencode.messaging.send_and_wait(prompt)   -- 2
      local action = opencode.ui.popup({                          -- 3
        content = response.text,
        title = hunk.file .. ":" .. hunk.line,
        actions = { "approve", "comment", "skip" },
      })
      if action == "comment" then
        -- user writing some comment here, or some small model predict what user want to say
      end
    end
  end,
})

That looks like a really great api.

As a side note, I might be limited by the product form I'm referencing. Since these are all nvim windows anyway, there should be some APIs that allow us to leave annotations anywhere we want to focus on, right? In this case, diffview is just an incidental detail.

Gather context -> Do something

That's all there is to it. The company gave me a Codex account, and I'm happy to spend my energy (or rather, let Codex spend its energy) on this project in my spare time. However, until then, I will likely still prioritize issues regarding code quality

I am leaving this here as a reminder; it does not necessarily mean performing a radical code refactoring

#322 (comment)

However, it's quite interesting to use this project to discuss and practice what constitutes a vibe coding-friendly architecture. I believe the previous direction was correct: simplify the core mechanism of the plugin as much as possible, and make all other features table-driven and pluggable.

I use diffview (these days, diffview-plus). It's easy to set up an after-the-fact diffview integration in your own config files.

Lazy keys spec (if you lazy load opencode.nvim):

keys = {
        { "<leader>odv", function ()
            local path = require("opencode.config_file").get_workspace_snapshot_path():wait()
            vim.cmd("DiffviewOpen -C" .. path)
        end, desc = "open session changes in diffview"},
}

Or vim.keymap.set:

vim.keymap.set("n", "<leader>odv", function()
    local path = require("opencode.config_file").get_workspace_snapshot_path():wait()
    vim.cmd("DiffviewOpen -C" .. path)
end, { desc = "open session changes in diffview"})

Once it's in a diff, just use the NeoVim default keybind do on a hunk in the current file and it will reset to before the change.
Defaults ]c and [c jump between changes.

With gitsigns, you can add a hunk to context if it needs revising like so:

gitsigns.opts.on_attach

function()
    -- other keymaps ...
    map("n", "<leader>oyh", function()
        vim.cmd("Gitsigns select_hunk")
        require("opencode.context").add_visual_selection()
    end, "send hunk to opencode context")
end

That pretty much covers the change-by-change workflow for me. Even in Cursor, accepting is more of a formality. The changes are already saved.

I don't want to discourage you if you intend to build a bespoke workflow and integrate diffview or another tool, but I landed here because I was searching for a workflow like this. Just posting in case this can help anyone else who might also be trying to figure out the setup.

I'm going to have to take another look at this. I've been doing my day job with this setup today, and noticed it's not properly isolating sessions. Might be something to do with how Opencode does its snapshots. I'm going to look into it. Also, I typoed the flag. It should be -C.

Turns out, Diffview was erroring out silently and just falling back to its standard :DiffviewOpen behavior. I have a habit of committing before asking the AI to write code, so it didn't look any different to me. The plain old git command git -C <snapshot> <ref> produces a proper diff, so I've opened a PR in Diffview-plus's repo to bring it to parity with git in this regard. If it's merged, I'll finish writing up the recipe and open a PR here too. The setup does change slightly, since it needs the snapshot hash:

        { "<leader>odv", function ()
            local path = require("opencode.config_file").get_workspace_snapshot_path():wait()
            local first_snapshot = require("opencode.git_review").get_first_snapshot()
            vim.cmd("DiffviewOpen \"-C=" .. path .. "\"" .. " " .. first_snapshot)
        end, desc = "diff against start of session"},

@Kortantic

ive been thinking about this same workflow and thanks for sharing these configs @Kortantic. I also want something like tuicr but more flexible in that it doesn't just review diffs. i often want context from outside the diffs, but I really like how tuicr persists sessions associated with a set of commits and provides an overlay for the comments. its probably outside the scope of this project but it just feels like this is something so right thats missing from all of these projects. I wrote a plugin for basically collecting my notes from lines/visual selections and now im realizing i could probably just use diffview and this plugin at the very least.

local M = {}

M.notes_file = vim.fn.stdpath("data") .. "/inline_notes.md"

local function setup_note_jump(buf)
  vim.keymap.set("n", "gf", function()
    local cursor_line = vim.fn.line(".")
    local lines = vim.api.nvim_buf_get_lines(0, 0, -1, false)
    for i = cursor_line, 1, -1 do
      local file, lnum = lines[i]:match("^## `(.+):(%d+%-?%d*)`$")
      if file and lnum then
        local start_lnum = lnum:match("^(%d+)")
        vim.cmd("edit +" .. start_lnum .. " " .. vim.fn.fnameescape(file))
        return
      end
    end
    vim.notify("inline-notes: no file reference found above cursor", vim.log.levels.WARN)
  end, { buffer = buf, desc = "Jump to note source" })
end

local function write_note(context, content)
  local file = io.open(M.notes_file, "a")
  if not file then
    vim.notify("inline-notes: could not open " .. M.notes_file, vim.log.levels.ERROR)
    return
  end
  local entry = string.format("## `%s:%s`\n\n%s\n\n---\n\n", context.file, context.line, content)
  file:write(entry)
  file:close()
  vim.notify("note saved")
end

function M.open_note_buffer(range)
  local context = {
    file = vim.fn.expand("%:p"),
    line = range and (range[1] .. "-" .. range[2]) or tostring(vim.fn.line(".")),
  }

  local buf = vim.api.nvim_create_buf(false, true)
  vim.bo[buf].filetype = "markdown"
  vim.bo[buf].bufhidden = "wipe"
  vim.bo[buf].swapfile = false
  vim.bo[buf].buftype = "nofile"

  vim.cmd("belowright split")
  local win = vim.api.nvim_get_current_win()
  vim.api.nvim_win_set_buf(win, buf)
  vim.api.nvim_win_set_height(win, 12)

  local written = false

  local function do_write()
    if written then
      return
    end
    written = true
    local lines = vim.api.nvim_buf_get_lines(buf, 0, -1, false)
    local content = table.concat(lines, "\n"):match("^%s*(.-)%s*$")
    if content ~= "" then
      write_note(context, content)
    end
  end

  local function close()
    do_write()
    if vim.api.nvim_win_is_valid(win) then
      vim.api.nvim_win_close(win, true)
    end
  end

  vim.api.nvim_create_autocmd("WinClosed", {
    pattern = tostring(win),
    callback = do_write,
    once = true,
  })

  vim.keymap.set("n", "<Esc>", close, { buffer = buf, noremap = true })

  vim.cmd("startinsert")
end

function M.open_notes_file()
  if vim.fn.filereadable(M.notes_file) == 0 then
    local f = io.open(M.notes_file, "w")
    if f then
      f:close()
    end
  end
  vim.cmd("edit " .. vim.fn.fnameescape(M.notes_file))
  vim.schedule(function()
    setup_note_jump(vim.api.nvim_get_current_buf())
  end)
end

function M.copy_notes_file()
  if vim.fn.filereadable(M.notes_file) == 0 then
    vim.notify("inline-notes: no notes yet", vim.log.levels.WARN)
    return
  end
  local f = io.open(M.notes_file, "r")
  if not f then
    vim.notify("inline-notes: could not read file", vim.log.levels.ERROR)
    return
  end
  local content = f:read("*a")
  f:close()
  vim.fn.setreg("+", content)
  vim.fn.setreg('"', content)
  vim.notify("notes copied to clipboard")
end

function M.clear_notes_file()
  local f = io.open(M.notes_file, "w")
  if f then
    f:close()
    vim.notify("notes cleared")
  else
    vim.notify("inline-notes: could not clear file", vim.log.levels.ERROR)
  end
end

function M.setup()
  vim.keymap.set("n", "<leader>ii", M.open_note_buffer, { desc = "Add inline note" })
  vim.keymap.set("v", "<leader>ii", function()
    local s = vim.fn.line("'<")
    local e = vim.fn.line("'>")
    M.open_note_buffer({ s, e })
  end, { desc = "Add inline note (range)" })
  vim.keymap.set("n", "<leader>io", M.open_notes_file, { desc = "Open notes file" })
  vim.keymap.set("n", "<leader>ic", M.copy_notes_file, { desc = "Copy notes file" })
  vim.keymap.set("n", "<leader>id", M.clear_notes_file, { desc = "Clear notes file" })

  vim.api.nvim_create_autocmd("BufReadPost", {
    pattern = M.notes_file,
    callback = function(ev)
      setup_note_jump(ev.buf)
    end,
  })
end

return M

@ujisati

From my personal perspective, I completely agree. I also believe there is some room for imagination here, especially since implementing these things as an nvim-plugin should be much simpler than with other tools; the Kortantic example is a perfect testament to that.

but I really like how tuicr persists sessions associated with a set of commits and provides an overlay for the comments. its probably outside the scope of this project but it just feels like this is something so right thats missing from all of these projects.

But I haven't had the energy to focus on this project lately. Could you expand further on this section? One aspect is what interesting requirements might emerge (personally, I'm more interested in things like context-aware prompt auto-generation or enhancement). Another potentially more important issue is how to "persuade" the owner to agree to or participate in this direction of discussion (if you've come up with any good ideas). After all, this is just a side project, and we don't have the capacity to take on too much maintenance overhead. Features like this should ideally be maintained through wikis or recipes in the future. The plugin itself should only provide a simple mechanism and remain agnostic of diffview.nvim or diffview-plus.nvim. Reviewing this design together in a "vibe-based" collaborative way might be a good approach. @ujisati

#318 (comment)

Thank you for joining the discussion!

@jensenojs

I also agree that we have to stay agnostic, we can think of providing hooks or building blocks for people to create their own workflow. I don't want this plugin to have 12 different workflows because it will be to hard to maintain. I would gladly add such features if the core api's are not enough. You can create features requests in that sense.

As @jensenojs said this is a side project. I do this on my spare time. My usage is simple and the current plugin workflow is enough for me.

Since my work moved to claude code, I only use this plugin for my personal projects, this means that I don't see issues immediately. I try to dedicate some time for maintenance and new features when I can.

We can now quickly jump from the output-window back to the main editing buffer, including git-diff, file, and symbol

As for nvim -> opencode, we currently have add_visual_selection (and also add_visual_selection_inline, though I don't quite understand yet why we need two separate add_visual APIs). However, I think things would be more interesting if we could append a comment structure to these visual_selections. After all, when we use add_visual_selection, the prompts are often centered around commenting on those specific chunks. In the TUI, I often just directly copy and paste the chunks I'm interested in and then add some comments. It's a bit messy, though.

Something like tuple = (context, comment), and then what we send to opencode is what we originally intended to say + a [tuple1, tuple2, tuple3]

I free that it has some potential to consolidate complexity and features. For example, the workflow in diffview-plus. Furthermore, there might be some reusable elements between this direction and your recent features.

While just vibing with it might result in a decent demo, I feel like there are probably quite a few corner cases here (Or work related to code maintainability), so I'm just finding a random spot to tuck this idea away. Design should be simple, but the gap between looking simple and being thoughtfully simple has made me decide to keep being lazy for a while longer.

The main difference between the 2 api is the the add_visual_selection contains some metadata like the file and line number

So in terms of having the ability to add comments on a diffview the add_visual_selection could be extended to add an optionnal comment.

I also think that we might want to add a mention like attached files on the input window referring the selection.

That would move us to the right direction for such a workflow.

I stumbled on this plugin yesterday,

https://github.com/vuki656/review.nvim

It looks pretty easy to integrate with our plugin.

I'll take a look at that plugin in a couple of days, but it does seem really interesting

I am still tied up with other matters. If it is not urgent, please give me some more time to refine a draft of a suitable integration method

I have started the design process, and I currently have a few requirements:

This plugin provides minimal, optional capabilities for commenting on selected sections
I found that the ideas from meow.review.nvim can be used as a reference.
The core code shouldn't be very extensive (though the compatibility code built around it might be)
Provide as much flexibility as possible by allowing users to choose between diffview(plus), review(from vuki656 and georgeguimaras), and other plugins in the form of recipes

It should be relatively simple, but I will probably put together a draft design document first

#499

With the new v2 api, It was relatively easy to add a review workflow. However the way diffs are saved in v2 (not as git worktree anymore) using a plugin like diffview would not work.

I implemented my own view for this

The commenting phase

With the new review process in v2 I will close this one as completed

Navigation Menu

Repository navigation

Feature : Better diff view #318

Lazy keys spec (if you lazy load opencode.nvim):

Or vim.keymap.set:

gitsigns.opts.on_attach

4 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Feature : Better diff view #318

Description

Activity

sudo-tee commented on Mar 12, 2026

jensenojs commented on Mar 12, 2026

jensenojs commented on Mar 13, 2026

jensenojs commented on Mar 13, 2026

sudo-tee commented on Mar 13, 2026

sudo-tee commented on Mar 19, 2026

jensenojs commented on Mar 19, 2026

jensenojs commented on Mar 19, 2026

wzj-zz commented on Mar 21, 2026

jensenojs commented on Apr 8, 2026

sudo-tee commented on Apr 8, 2026

jensenojs commented on Jun 10, 2026

jensenojs commented on Jun 10, 2026

Kortantic commented on Jun 11, 2026

Lazy keys spec (if you lazy load opencode.nvim):

Or vim.keymap.set:

gitsigns.opts.on_attach

4 remaining items

Kortantic commented on Jun 12, 2026

Kortantic commented on Jun 13, 2026

ujisati commented on Jun 14, 2026

jensenojs commented on Jun 15, 2026

sudo-tee commented on Jun 15, 2026

jensenojs commented on Jul 15, 2026

sudo-tee commented on Jul 15, 2026

sudo-tee commented on Jul 31, 2026

jensenojs commented on Jul 31, 2026

jensenojs commented on Aug 3, 2026

jensenojs commented on Aug 7, 2026

sudo-tee commented on Sep 25, 2026

sudo-tee commented on Oct 17, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions