[mini.diff] Highlight group for entire changed lines in overlay

[net]

Contributing guidelines

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md

Module(s)

mini.diff

Description

I would like to set up overlay highlights for mini.diff so that it looks like a standard diff: changed lines highlighted red in the source and green in the buffer.

While right now mini.diff has a highlight group MiniDiffOverAdd for added buffer lines, there is no highlight group that spans entire changed buffer lines.

Additionally, setting the MiniDiffOverChange background to None doesn't fall through to the MiniDiffOverContext background, leaving an unaesthetic gap in the context line background.

For reference, this is how I'd like to color mini.diff overlays:

This is how they can be colored right now:

[echasnovski]

Thanks for the suggestion!

The current design is more aligned with how built-in Neovim diff does it (see :h diff). I'll think about possibly a less intrusive way of achieving GitHub like highlighting, but preserving the current one is still a priority.

The best thing to do right now seems to be link MiniDiffOverChange to MiniDiffOverContext (or make it have background with a slightly different shade). So something like this: vim.api.nvim_set_hl(0, 'MiniDiffOverChange', { link = 'MiniDiffOverContext' }).

[net]

I think both styles can be supported with these groups:

• MiniDiffOverAdd – full added line
• MiniDiffOverDelete – full deleted line
• MiniDiffOverChange – changed text
• MiniDiffOverContext – full changed source line (modified to span the full line without gaps)
• MiniDiffOverChangeLine – full changed buffer line, unstyled by default (new)

If you wanted to support GitHub-style highlighting where the changed text gets a slightly darker red/green background:

• MiniDiffOverAdd – full added line
• MiniDiffOverDelete – full deleted line
• MiniDiffOverChange – changed text
• MiniDiffOverChangeSource – changed text in source, links to MiniDiffOverChange by default (new)
• MiniDiffOverChangeBuffer – changed text in buffer, links to MiniDiffOverChange by default (new)
• MiniDiffOverContext – full changed source line (modified to span the full line without gaps)
• MiniDiffOverChangeLine – full changed buffer line, unstyled by default (new)

The "Neovim diff" style can still be the default, and anyone who wants a more traditional style will be able to accomplish it by updating the highlight groups.

[JakobStr]

@net Did you manage to get a nice configuration for your suggested coloring?
This is the one thing I am really missing in this plugin. In the current state it is easier for me to open something like lazygit using delta to visualize the changes, but having visualized inline changes would be a gamechanger!
Especially if you change multiple lines, it gets very confusing. Keep up the great work @echasnovski.

[net]

@JakobStr unfortunately, I don't believe it's possible without the additions I suggested :/

[echasnovski]

This should now be resolved on latest main with addition of two new groups: MiniDiffOverChangeBuf and MiniDiffOverContextBuf. This allows having GitHub-style diff highlighting with something like this:

local hi = function(name, bg) vim.api.nvim_set_hl(0, name, { bg = bg }) end
hi('MiniDiffOverAdd', '#104010') -- regular green
hi('MiniDiffOverChange', '#600000') -- saturated red
hi('MiniDiffOverChangeBuf', '#006000') -- saturated green
hi('MiniDiffOverContext', '#401010') -- regular red
hi('MiniDiffOverContextBuf', '#104010') -- regular green
hi('MiniDiffOverDelete', '#401010') -- regular red

This is indeed not 100% solution, as with config.options.linematch = 0 change hunks with unequal amount of reference and buffer lines will have reference changes highlighted with saturated red (and not regular red). The buffer part will be highlighted as regular green as MiniDiffOverContextBuf is used in this case (and not MiniDiffOverChangeBufmostly to avoid the situation when both reference and buffer parts are highlighted the same; as is with default highlight groups). But I think in practice it is at least a 95% solution, as I don't expect the situation of unequal number of lines in change hunks to be that common. It should be good enough.

[net]

Looks great, thank you!!

[JakobStr]

Amazing @echasnovski, thanks a lot!