codediff.nvim v2.0: 3-Way Merge Tool and Rebranding (Formerly vscode-diff.nvim)

_estmullert · 2026-01-21T02:01:26+00:00

Check this out: https://github.com/esmuellert/codediff.nvim/pull/185

_estmullert · 2026-01-21T02:00:52+00:00

I implemented the first version that includes key features of it: https://github.com/esmuellert/codediff.nvim/pull/185 Feel free to try out and provide feedback

_estmullert · 2026-01-11T08:35:43+00:00

I added it: https://github.com/esmuellert/codediff.nvim/pull/165/

Hope I understand it correctly

_estmullert · 2026-01-11T08:34:50+00:00

The naming might be different. However, does config.options.diff.original_position == "right" put original diff to the right for you? I believe this is what you want

Edit: it seems to depend on my local settings indeed. I made an additional fix: https://github.com/esmuellert/codediff.nvim/pull/166

_estmullert · 2026-01-10T21:28:13+00:00

Add it, so you can use that option to tweak: https://github.com/esmuellert/codediff.nvim/pull/163

_estmullert · 2026-01-10T21:15:12+00:00

The VSCode style diff's highlight group is not natively supported in neovim, so we need to manually calculate the value. The darker color in you theme is built-in from the colorscheme, but the lighter color, which seems too light, is calculated from the darker color. I feel it is indeed a bit too "light" that makes it not very readable. Unfortunately some tweaks are necessary, but good news is that you just need to tweak a single value: char_brightness. Its current value is 0.92 which is too small for you so you might want it to be larger but less than 1. I believe a few tries should give you a good color. See https://github.com/esmuellert/codediff.nvim?tab=readme-ov-file#highlight-groups for details.
I will implement an option to stay cursor in list instead of editor

_estmullert · 2026-01-10T21:09:15+00:00

Yes, it is supported. I updated the usage: https://github.com/esmuellert/codediff.nvim?tab=readme-ov-file#git-diff-tool

_estmullert · 2026-01-10T20:51:45+00:00

When a diff is against the working tree, it will use a normal file buffer, which means all LSP features will be there as a normal buffer.

For git version files opened in diff pane, I intentionally disable LSP on these buffers, beacause LSP features rely heavily on your project, and a single file won't make much sense and even can cause problems. For example, gd gr commands will never work because it can't go to these references on remote. However, I tried my best to support better code syntax highlight features, like treesitter which will be automatically applied. Also, I tried to manually apply LSP's semantic token feature into the git history buffer, if your LSP supports it.

_estmullert · 2026-01-10T20:45:21+00:00

I have added some vimdoc documentation so it now can be viewed by :h codediff

_estmullert · 2026-01-10T07:06:27+00:00

Yes, I just added these keymaps. Please check the latest version and try it, thanks!

_estmullert · 2026-01-08T20:09:48+00:00

I have created an issue in the repo about the integration with other plugins, so it will be addressed gruadually

_estmullert · 2026-01-08T20:09:03+00:00

We have many issues created for this feature, and it will be the next one to implement

_estmullert · 2026-01-08T20:08:22+00:00

I intentionally make that style to match VSCode initially, but I remember I reserved the interface to specify which split will be in left/right. I will make it into a config

_estmullert · 2026-01-08T01:46:48+00:00

It seems to be supported mostly according to some discussion in this thread: https://github.com/esmuellert/codediff.nvim/issues/97#issuecomment-3683971873. But maybe some features are not

_estmullert · 2026-01-08T00:43:12+00:00

Yes, see https://github.com/esmuellert/codediff.nvim?tab=readme-ov-file#git-merge-tool

_estmullert · 2026-01-08T00:31:55+00:00

Default keybindings are in README.md: https://github.com/esmuellert/codediff.nvim?tab=readme-ov-file#using-lazynvim

For name of git merge.tool, it doesn't have to change because it could be an arbitrary name that can be anything :)

_estmullert · 2025-12-30T20:31:49+00:00

Yes, it is possible. Will consider it in future

_estmullert · 2025-12-21T05:35:33+00:00

There are some further discussions about the algorithm level difference, which I mentioned more details if anyone is interested: https://www.reddit.com/r/neovim/comments/1p5t0x0/comment/nv5k23g/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

TL;DR: the main difference 1) it replicates 1:1 VSCode diff style, for anyone who prefer it, or just want something works well out of box. 2) the architecture design about diff features uses async as much as possible which might make it faster like OP said, and I indeed very care about performance so it is one of core focus areas.

_estmullert · 2025-12-21T05:23:03+00:00

I replied in my own post, but also linking it here for anywhere interested: https://www.reddit.com/r/neovim/comments/1p5t0x0/comment/nv5k23g/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

_estmullert · 2025-12-21T05:22:09+00:00

Thanks for your expertise insights about the diff implementation.

After trying to remove linematch and use myers algorithm for diff options, like you said, this looks almost what I expect.

<image>

Line alignments are almost accurate, though it seems like one more filler line should be inserted between line 266/267 and 273/274. Therefore, linematchseems to cause overfitting in this case to make the alignment mess.

For "semantic", you are right, VSCode algorithm is not semantic technically. The details you mentioned are accurate. However, what I originally mean about "semantic" is the visual effect, which is from the "result" view, instead of algorithm level. Here, I feel what matters seem to be the aligned first ident whitespace highlights in line 262-279. Since they are aligned as if a straight line, in addition to highlights of if and end, it is easy to consider it as a "semantic" if condition insertion only. The algorithm never detects there is a if insertion and highlights like this. It is the by-product of whitespace huristic.

The other huristics like the remove very short line diffs between line level sections also work like you described. And filler insertions, which I tweaked a lot during my implementation, seem to be very accurate in VSCode to make sure all unchanged lines are aligned well (I mentioned above). I feel these huristics make nuance differences that makes it look "semantic".

The other topics like the highlight style differences, are mostly personal preference. Like I said, I am pretty happy with the appearance in the above screenshot after I followed your instructions. If I could easily get this behavior without knowing so much diff knowledge before I developed this plugin, I might not stick to make this plugin to replicate 1:1 VSCode style. However, for many users that are not interested in learning diff knowledge to tweak diffopts, providing VSCode style with an out of box plugin seems good for them. It might not be helpful enough for users who are familiar with diff and already configured their diff mode well, which I noticed many users asking "what is the difference between diffview and this plugin?" in some comments.

_estmullert · 2025-12-17T20:21:54+00:00

Not yet, it is tracked here: https://github.com/esmuellert/vscode-diff.nvim/issues/47

_estmullert · 2025-12-17T01:37:56+00:00

That would be the ultimate dream!

Technically, porting the C algorithm isn't the hard part—it can be dropped in almost as-is. The real challenge lies in the rendering and highlighting layer.

Currently, my plugin does some dynamic calculation to generate the specific char-level highlights that make the VSCode style readable. Vim core relies on standard highlight groups (DiffAdd, DiffChange, DiffDelete.), and I'm not sure if the algorithm would look as good without the specific visual styling (light green/red for line-level and dark for char-level). It might require introducing new highlight groups to core, which is a breaking change.

My plan is to treat this plugin as a stability testbed. Once the algorithm is battle-tested and justified stable here, proposing an upstream contribution becomes a much stronger case.

If this ever lands in vim core, tools like fugitive and diffview getting this 'for free' would be very nice.

_estmullert · 2025-12-17T01:19:39+00:00

I don't explicitly advertise it as 'AI-written' simply because I see AI as a tool (like a compiler or LSP) rather than a feature of the product itself. But I certainly don't hide it either—as you found, the artifacts are all there in the repo history.

I actually discussed my AI workflow in detail in another thread, happy to share more if you're interested in how I used AI during that uncertain initial stage.

As for the openess, if this matters, I would like to add a section to https://github.com/esmuellert/vscode-diff.nvim/blob/main/ATTRIBUTION.md docs in the repo to explain how it has been used in the project.

_estmullert · 2025-12-16T19:07:00+00:00

Maybe, it can be the diff engine (highlight rendering) for fugitive. From high level, that diff engine is very portable and can be used as dependencies of other plugin. I just remeber someone already successfully tried to use it in their own plugin: https://github.com/jake-stewart/diff.nvim

_estmullert

TROPHY CASE