levouh/tint.nvim

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
Screenshot 2024-01-28 at 02 17 17

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.

Screenshot 2024-01-28 at 21 07 37

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:

image

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

image

@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.