bug: Normal highlight slightly different just after running :Lazy build

[Iron-E]

Did you check docs and existing issues?

• I have read all the lazy.nvim docs
• I have searched the existing issues of lazy.nvim
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

0.9.0

Operating system/version

6.2.12-arch1-1

Describe the bug

It seems the color of Normal is modified temporarily after executing :Lazy build. For example:

• in my personal colorscheme, Normal's background color is "#202020". During :Lazy build, it is "#353535"
• in the default colorscheme, Normal is cleared. During :Lazy build, the background "#ff00ff"

Steps To Reproduce

1. Add a build hook to any plugin, e.g.:

   {'folke/lazy.nvim', tag = 'stable', build = function()
       vim.print(vim.g.colors_name, vim.api.nvim_get_hl(0, {name = 'Normal', link = false}))
       vim.defer_fn(function() vim.print(vim.g.colors_name, vim.api.nvim_get_hl(0, {name = 'Normal', link = false})) end, 5000)
   end},

2. Start nvim, then run :hi Normal to verify the correct Normal highlight color.
3. :Lazy build <plugin>, it will print an incorrect Normal color first then 5 seconds later it will print the correct one.

Expected Behavior

The Normal highlight group should remain unmodified while running :Lazy build, so that colorscheme plugins (e.g. mini.colors) can run update hooks.

Repro

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/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", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  {"folke/tokyonight.nvim", build = function()
    vim.cmd.colorscheme("tokyonight")
    vim.print(vim.g.colors_name, vim.api.nvim_get_hl(0, {name = 'Normal', link = false}))
    vim.defer_fn(function() vim.print(vim.g.colors_name, vim.api.nvim_get_hl(0, {name = 'Normal', link = false})) end, 5000)
  end},
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")

[folke]

Can't reproduce:

Your issue is most likely due to a plugin or your init.lua that's overriding a color, without doing it inside a ColorScheme autocmd.

[Iron-E]

Odd, I even got it to reproduce using the nvim --clean -u minimal.lua. My config shouldn't be loading there (unless I'm missing something?)

[Iron-E]

@folke (sorry for the ping) on closer inspection, the bg for Normal in your screenshot is wrong for tokyonight. It should be 2369595. So it seems that you actually have reproduced the issue: the Normal bg was different while build was running.

This minimal repro might be better:

1. Let the build complete
2. :q the lazy floating window
3. Enter insert mode
4. View :messages

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/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", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  {"folke/tokyonight.nvim", build = function()
    vim.cmd.colorscheme("tokyonight")
    vim.print(vim.g.colors_name, vim.api.nvim_get_hl(0, {name = 'Normal', link = false}))
  end},
}

require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.api.nvim_create_autocmd('InsertEnter', {callback = function()
  vim.print(vim.g.colors_name, vim.api.nvim_get_hl(0, {name = 'Normal', link = false}))
end})

Output of rm -rf .repro; nvim --clean -u minimal.lua:

[folke]

You mean the the colors are different when the build is ran during startup? Then yes, that's normal

[folke]

What's the actual problem you're trying to fix here? Why do you even load a colorscheme in a build function?

Check the readme for colorscheme. You need to pay special attention it's loaded at the correct time, to prevent issues with plugins that dont properly use ColorScheme

[Iron-E]

Weirdly, it's only the Normal bg that seems to be affected. I've read the README for colorschemes, it happens on tokyonight with priority = 1000 too.

How can it be prevented? It's preventing with two things:

1. mini.colors exporting colorschemes with cterm attributes accurately on build (see here)
2. Exporting colorschemes to other formats accurately on build (see here)

[folke]

lazy doesn't change the colors. The lazy build thing just loads the plugin and runs the build function.

updated repro:

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/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", lazypath })
end
vim.opt.runtimepath:prepend(lazypath)

local test = {}

local function t(msg)
  test[#test + 1] = { msg, vim.g.colors_name, vim.api.nvim_get_hl(0, { name = "Normal", link = false }) }
end

t("before_lazy")
-- install plugins
local plugins = {
  {
    "folke/tokyonight.nvim",
    build = function()
      t("start_build")
      vim.cmd.colorscheme("tokyonight")
      t("end_build")
    end,
  },
}

require("lazy").setup(plugins, {
  root = root .. "/plugins",
})
t("after_lazy")

vim.defer_fn(function()
  vim.cmd([[:Lazy build tokyonight.nvim]])
end, 1000)

vim.defer_fn(function()
  t("after_defer")
  for _, tt in ipairs(test) do
    print(vim.inspect(tt))
  end
end, 2000)

[folke]

What is wrong here according to you?

[folke]

The problem is probably that your build function runs before Neovim loaded the default colorscheme

[folke]

Although it still all works as expected for me when I delete .repro and remove the :Lazy build from the repro.lua

[Iron-E]

This repro also bugs when doing :Lazy build tokyonight.nvim manually, after the colorscheme loads. Not sure why the updated repro doesn't show the issue, but my minimal repro from before does it 100% of the time for me

Edit: actually, all of those screenshots you posted had the wrong bg for Normal. So the bug was reproduced in all of them

[folke]

The thing is that it doesn't for me. What NEovim version are you using?
Also, as you can see from my screenshots it all works.

100% certain this is user error. I'm sure you'll figure it out.

[Iron-E]

I'm using Neovim 0.9.0, but it also happens on recent nightly builds. I can try it on another machine later just to make sure it's not something in my environment messing it up. Feel free to ignore until then

[folke]

I've spent too much time on this already as is. I'm not going to debug your config or your plugins. This is not a lazy issue. It might be related to builds running early during startup (although it all works as expected for me). If that's the case just defer your build command

[Iron-E]

For anyone who comes across this issue,

I tried it on another machine. Wiped it clean, fresh install of Windows (my normal machine is Linux). Downloaded Neovim 0.9.0 right from Github, no alternative distribution. Checked the hashes to make sure they matched (i.e. no download issues).

Followed the instructions in this comment and got the same result. Tried multiple different terminals (powershell and cmd), same result.

• My config and my plugins have never touched this computer. They have nothing to do with this issue whatsoever.
• It's not a case of early startup, because it also reproduces when manually running :Lazy build.
• Deferring the build command works, ~5000ms on either machine will make the groups go back to normal (as shown in the OP of this issue). It's the only way I've found to reliably solve this problem.