tint_background_colors does not work in neovim v0.10
antonk52 opened this issue · 6 comments
Thank you for your work!
I tried setting up this plugin and noticed that in the dev build of nvim v0.10.x the tint_background_colors
feature does not work.
To reproduce
require('tint').setup({ tint = -35, tint_background_colors = true })
Both have focus on the right splits, left splits are tinted.
Above: neovim v0.9.5
Below: neovim v0.10.0-dev-2210+g38bb0e1da
I just updated to HEAD
(NVIM v0.10.0-dev-2221+g47cd532bf
) and I cannot reproduce this.
Do you have a set of steps to get to this point? E.g. are you opening files after opening nvim
itself, or are you opening them with -o
, etc.?
I would also assume that nothing in your configuration changed between the two nvim
versions?
Do you have a set of steps to get to this point? E.g. are you opening files after opening nvim itself, or are you opening them with -o, etc.?
The way I could repro this is nvim init.lua
then create a split with :vs<cr>
. Repeat with a master build.
I would also assume that nothing in your configuration changed between the two nvim versions?
Correct, the configuration is identical.
I used a prebuilt binary from the release for macos from the nightly build built from 2cd76a7
I tried disabling all plugins but tint and using a built in blue
theme and could repro this issue
I was able to narrow down the issue to this minimal init.lua
vim.opt.termguicolors = true
vim.cmd[[color blue]]
-- Bootstrap lazy.nvim plugin manager {{{1
local PLUGINS_LOCATION = vim.fn.expand('~/dot-files/nvim/plugged')
local lazypath = PLUGINS_LOCATION .. '/lazy.nvim'
if not vim.loop.fs_stat(lazypath) then
vim.fn.system({
'git',
'clone',
'--filter=blob:none',
'https://github.com/folke/lazy.nvim.git',
'--branch=stable', -- latest stable release
lazypath,
})
end
vim.opt.rtp:prepend(lazypath)
require('lazy').setup({
{ 'levouh/tint.nvim', opts = { tint = -35, tint_background_colors = true } },
}, {
root = PLUGINS_LOCATION,
})
Screenshot for reference. Above nvim 0.9.5, below the nightly build.
Just for reference, using a different minimal init.lua
like the following, I am able to reproduce with the content in /tmp/init.lua
and running with nvim -u /tmp/init.lua
:
local target = vim.fs.joinpath("/", "tmp", "nvim-test")
local remove_paths = {
vim.fn.expand(vim.fs.joinpath(vim.fn.stdpath("data"), "site")),
vim.fn.expand(vim.fs.joinpath(vim.fn.stdpath("data"), "site", "after")),
vim.fn.expand(vim.fs.joinpath(vim.fn.stdpath("config"), "after")),
vim.fn.expand(vim.fn.stdpath("config")),
}
for _, remove_path in ipairs(remove_paths) do
vim.print("Removing " .. remove_path)
vim.opt.runtimepath:remove(remove_path)
vim.opt.packpath:remove(remove_path)
end
vim.opt.runtimepath:append(vim.fn.expand(target))
vim.print(vim.opt.runtimepath:get())
vim.opt.packpath:append(vim.fn.expand(target))
vim.print(vim.opt.packpath:get())
vim.opt.termguicolors = true
local plugin_path = vim.fs.joinpath(target, "pack", "tmp", "opt", "tint.nvim")
if vim.fn.isdirectory(plugin_path) ~= 1 then
vim.fn.system({ "git", "clone", "https://github.com/levouh/tint.nvim", plugin_path })
end
vim.cmd("packadd tint.nvim")
vim.cmd("colorscheme blue")
require("tint").setup({ tint = -75, tint_background_colors = true })
The namespaces in this minimal setup getting noted as 2
and 3
, and when running something like:
:lua =vim.api.nvim_get_hl(3, { name = "Normal" })
:lua =vim.api.nvim_get_hl(2, { name = "Normal" })
I get output like:
{
bg = 24,
ctermbg = 18,
ctermfg = 220,
fg = 10782720
}
{
bg = 135,
ctermbg = 18,
ctermfg = 220,
fg = 16766720
}
which notes that at least within the namespaces, the colors are being tinted correctly.
Further, with a single window open, I can do something like:
:lua vim.api.nvim_win_set_hl_ns(1000, 2) -- default
:lua vim.api.nvim_win_set_hl_ns(1000, 3) -- tint
and see it change correctly. Not 100% sure why things would act any different when calling this via autocmds, however this seems to only work when there is 1 window visible, which brings into account Normal
versus NormalNC
.
@antonk52 - the problem seems to arise when NormalNC
is not defined, which makes sense (see :h NormalNC
). I'm not entirely sure what changed upstream to cause this, but if you add something like vim.cmd("hi NormalNC guifg=#ffd700 guibg=#000087")
, you should see it start working with one of the minimal examples noted here. Obviously for your own configuration, you can add the appropriate definition as well.
I am not really sure that this is something that I can solve here in this plugin as I do not want to make assumptions about people's color scheme choices, so ensuring/spoofing a setup of NormalNC
feels like the wrong thing to do here. I think linking it to Normal
feels like it would be a mildly unobtrusive way to solve the problem, but I will have to think about it.
Let me know if this works for you in the mean time or not (making sure your colorscheme defines NormalNC
before you setup tint
).
Thanks for looking into this. I can verify that setting NormalNC
highlighting group solves the issue for me.
Latest Neovim Nightly has some breaking changes affecting highlight groups, took me quite sometime to ajust my config ..
Now my config seems to be working fine except the NvimTree, tinting is quite weird there.. other file browsers like Oil or NeoTree are working just fine but NvimTree is behaving weird.
By chance are you using NvimTree? Have you noticed anything special there? Perhaps some HL group missing? (just wondering if this is something similar to NormalNC above)
ie: I see the parent dir + one go file getting tinted and another file not getting tinted:
Since it works fine with other file browsers I supposed something is broken in the HL groups, just couldn't find out what yet
Another example:
In here all directories + a.out
get tinted, the rest of the files don't
@rodhash I do not use NvimTree, but if you have a way to reproduce it (an init.lua
with a minimal set of plugins installed to reproduce the issue) I am happy to try to help debug.
You can also try calling :lua require("tint").refresh()
manually to see if it is indeed an issue with load ordering. This will force tint
to re-evaluate all loaded colors, etc. and update its highlight namespaces accordingly. If that doesn't work, you can try :hi link NormalNC Normal
(I don't fully recall the syntax, but link NormalNC -> Normal
) and then refresh again and see if that works. That would tell if you if it is the same issue as noted here.