mini.diff change algorithm: different from others?

[dyfrgi]

Contributing guidelines

• I have read CODE_OF_CONDUCT.md

Module(s)

mini.diff

Question

I am trying out mini.diff and I noticed that it has a very different idea of what is changed vs new from what I do. gitsigns and lualine are closer, though they're also not perfect.

It is of course a hard problem, as "changed" vs "some deleted and some new" is a semantic question, not a structural one, and most diff tools don't do semantics.

Here's a little example of what I'm talking about:

This shows the signs from gitsigns on the far left column and mini.diff next to it.

And here is an excerpt from git diff for that section (blank line at start is intentional, but this is not the start of a hunk):

-require("lazy").setup({
+require("config.lsp")
+require("config.telescope")
+require("config.treesitter")
+require("config.formatting")
+require 'blink-cmp'.setup()
+require 'lualine'.setup {}
+require 'gitsigns'.setup {}
+require 'mini.git'.setup {}
+require 'mini.diff'.setup(
+  {
+    view = {
+      style = 'sign',
+      signs = { add = '+', change = '~', delete = '-' },
+    },
+  }
+)
+

It seems like mini.diff is just treating a hunk as all changed if there's both - and + in it. Or something close to that - there is actually one line in this file for which mini.diff shows it as added, and it's right between some deleted stuff and some added stuff, though right after an unchanged non-whitespace line.

Anyway, I wanted to ask if it's intentional that it's so different. I haven't explored it enough to fully understand the behavior. If I add 121 lines and delete 48, I don't expect to see all the new lines except for one be counted as changed, so it's definitely confusing so far.

[echasnovski]

Both 'mini.diff' and 'lewis6991/gitsigns.nvim' use Neovim's vim.diff() to compute hunk information. So whichever data it returns is used to make decision about how two versions of text (buffer and reference) differ in terms of hunks. Each hunk is basically a two ranges of consecutive lines: one range for buffer lines and the other for reference lines. The hunk is decided to have "change" type if it contains both ranges, "add"/"delete" if there is only range in buffer/reference lines.

With that said, there are several possible explanations here:

• 'mini.diff' by default uses "histogram" algorithm for computing hunks and 'gitsigns.nvim' uses "myers".
• 'mini.diff' also uses linematch option which greatly improves hunk readability. It basically runs more complex steps to try and match which exactly lines were changed and not simply report "48 deleted and 121 added". This feature is available on Neovim>=0.9 (maybe you use 0.8?).

And here is an example of how similar changes look for me (with overlay enabled to see precisely which lines it thinks were changed; green/cyan line numbers are added/changed; dot in number column denotes virtual line):

Here is the "before" (reference) and "after" (buffer) lines used for this:

lua
-- Before
require('lazy').setup({
-- Some code
})

```lua
-- After
require("config.lsp")
require("config.telescope")
require("config.treesitter")
require("config.formatting")
require("blink-cmp").setup()
require("lualine").setup({})
require("gitsigns").setup({})
require("mini.git").setup({})
require("mini.diff").setup({
	view = {
		style = "sign",
		signs = { add = "+", change = "~", delete = "-" },
	},
})

A mild note: having both 'gitsigns.nvim' and 'mini.diff' enabled for a daily usage can result in hard to spot issues. It probably has nothing to do with this question, though.

If I add 121 lines and delete 48, I don't expect to see all the new lines except for one be counted as changed, so it's definitely confusing so far.

Sorry, I didn't get that. Would you mind posting a relatively small example of "before" and "after" lines along with the result you get (and 'mini.diff' setup if it will differ from the already posted one). This way we can have a more meaningful discussion.