Open kmoschcau opened 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 :)
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.
I think both of these problems can be solved by setting
default = true
on the twonvim_set_hl
calls. See:h :hi-default
.