refractalize / oil-git-status.nvim

55 stars 6 forks source link

The custom highlight groups don't survive a colorscheme change and ignore colorscheme overrides #4

Open kmoschcau opened 7 months ago

kmoschcau commented 7 months ago

I think both of these problems can be solved by setting default = true on the two nvim_set_hl calls. See :h :hi-default.

refractalize commented 7 months ago

Ok - so part of this is fixed with setting default = true, but it will reset highlights back to the defaults set in this plugin (links to DiagnosticSignInfo and DiagnosticSignWarn resp). If you want to maintain your own custom highlights after a colorscheme change you'll need to handle the ColorScheme event like this:

local function set_highlights()
  for _, hl_group in pairs(oil_git_status.highlight_groups) do
    if hl_group.index then
      vim.api.nvim_set_hl(0, hl_group.hl_group, { fg = "#ff0000" })
    else
      vim.api.nvim_set_hl(0, hl_group.hl_group, { fg = "#00ff00" })
    end
  end
end

vim.api.nvim_create_autocmd("ColorScheme", {
  pattern = "*",
  callback = set_highlights,
})

set_highlights()

If you've got suggestions for better highlight defaults for this plugin let me know - probably best just to ship better defaults :)

kmoschcau commented 7 months ago

I was looking at this from the perspective of a scheme maintainer. The scheme would override the highlights after the plugin is loaded. The color scheme overrides work with the latest patch now, so your snippet isn't needed in that case.

As for more sensible defaults, I'd use something green for the staging area and something red for the worktree. Just like git status --short does.

Edit: Oh and it might be good to have OilGitStatusIndex and OilGitStatusWorkingTree highlights, which either provide a custom default or link to some built-in groups (like DiffAdd and DiffDelete). Then have all OilGitStatusIndex* groups link to OilGitStatusIndex and the same for …WorkingTree respectively.