Feature : Better diff view

[jensenojs]

i also want this

• Planned / In progress features #43 (comment)

sth like

• https://github.com/backnotprop/plannotator
• https://github.com/agavra/tuicr

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.

[sudo-tee]

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

[jensenojs]

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.

[jensenojs]

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.

[jensenojs]

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...

[sudo-tee]

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

[sudo-tee]

@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.

[jensenojs]

@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 🤣.

[jensenojs]

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

• Moving to an organization cursortab/cursortab.nvim#59
• [FEATURE]: Context-Aware Prompt Enhancement anomalyco/opencode#10237

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

[wzj-zz]

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

[jensenojs]

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,
})

[sudo-tee]

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.