-
Notifications
You must be signed in to change notification settings - Fork 365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug: Load colorscheme when installing will set colorscheme twice #488
Comments
@leonasdev Did you managed to fix this? I'm having the same issue with colorschemes and modified highlights. |
I dont think I fully understand the issue. Do you mean that your customizations to the colorscheme dont take effect during installation? If that's what you mean, then yes, that is how it should work. The colorscheme used during installations is a temporary colorscheme and is loaded before any plugin spec has been loaded. Once installation finishes, the real colorscheme (with customizations) will be loaded. |
Hey @folke , the thing is after installation the custom highlights in colorscheme plugin are not being applied. As a side note, thank you for lazy.vim, I just migrated from packer and this is another level. Master work |
I see what's happening here. During installation, we do It's the same as doing |
Should be fixed now |
Regardless, its always advised to do any custom changes in a |
Oh I see, I did not know that was the way. local function fix_monokai()
local hl = vim.api.nvim_set_hl
local grp = vim.api.nvim_create_augroup("FixMonokai", { clear = true })
vim.api.nvim_create_autocmd(
"ColorScheme",
{
pattern = "monokai",
callback = function()
hl(0, "normal", { ctermfg="none" })
hl(0, "cursorline", { bg="#272727" })
hl(0, "linenr", { fg="grey" })
end,
group = grp,
desc = "Fix background and other colors for monokai colorscheme",
}
)
end
return {
{
"tanvirtin/monokai.nvim",
lazy = false,
priority = 1000,
init = fix_monokai,
config = function()
vim.cmd.colorscheme("monokai")
end,
},
} It does not work on Lazy install (highlights are not applied) By reading https://github.com/folke/lazy.nvim#%EF%B8%8F-startup-sequence, I guess the automatic Lazy installation on startup is being called first, (with its colorscheme call). I know I could manually move the What would be the proper |
Just move it to the beginning of your config method |
It works perfectly now!! Thank you for your help❤️❤️ |
Thanks, It works now. Anyhow, shouldn't |
OK -- the problem I was having was in the use of
as part of the plugin definition. it causes the colorscheme to be re-loaded at an unknowable bad time re-overriding my overrides. What's curious about that was that I even hacked the colorscheme plugin to do a print, but that print never showed up during this stealth plugin load.
Update: i think the problem is this particular colorscheme uses some async stuff inside and thats whats breaking it. So I am just moving past this by forking that repo and making my own changes directly inside. |
Did you check docs and existing issues?
Neovim version (nvim -v)
0.8.1
Operating system/version
Ubuntu 22.04
Describe the bug
It seems that if you set lazy's configuration with:
Lazy.nvim will set
:colorscheme some_colorscheme
on some point.So, let say if you have this plugin spec:
Then the startup sequence will be like:
somebody/some_colorscheme
somebody/some_colorscheme
2-1. set colorscheme to
some_colorscheme
2-2. set highlight
NormalFloat
'sbg
tonone
some_colorscheme
NormalFloat
has been overridden to defaultSo, how to guarantee I can load colorscheme before all the other start plugins, at the same time, I can load this colorscheme during installing without overriding the highlights setup?
Steps To Reproduce
folke/tokyonight.nvim
with the following spec:tokyonight
folke/which-key.nvim
black
as expected.Expected Behavior
Colorscheme loaded with the user defined config and should not load twice.
Repro
The text was updated successfully, but these errors were encountered: