Skip to content
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

Closed
3 tasks done
leonasdev opened this issue Feb 4, 2023 · 12 comments · Fixed by #505
Closed
3 tasks done

bug: Load colorscheme when installing will set colorscheme twice #488

leonasdev opened this issue Feb 4, 2023 · 12 comments · Fixed by #505
Labels
bug Something isn't working

Comments

@leonasdev
Copy link

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 exsiting issues of plugins related to this issue

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:

install = {
  -- try to load one of these colorschemes when starting an installation during startup
  colorscheme = { "some_colorscheme" },
},

Lazy.nvim will set :colorscheme some_colorscheme on some point.

So, let say if you have this plugin spec:

{
  "somebody/some_colorscheme",
  lazy = false, -- make sure we load this during startup if it is your main colorscheme
  priority = 1000, -- make sure to load this before all the other start plugins
  config = function()
    vim.cmd("colorscheme some_colorscheme")
    vim.api.nvim_set_hl(0, 'NormalFloat', { bg='none' })
  end
},

Then the startup sequence will be like:

  1. Install and loading somebody/some_colorscheme
  2. Execute config function of somebody/some_colorscheme
    2-1. set colorscheme to some_colorscheme
    2-2. set highlight NormalFloat's bg to none
  3. lazy.nvim trying to load colorscheme: some_colorscheme
  4. Highlight NormalFloat has been overridden to default

So, 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

  1. Install folke/tokyonight.nvim with the following spec:
    {
      "folke/tokyonight.nvim",
      lazy = false,
      priority = 1000,
      config = function()
        require("tokyonight").setup()
        vim.cmd.colorscheme("tokyonight")
        vim.api.nvim_set_hl(0, 'NormalFloat', { bg='#FFFFFF' })
      end
    }
  2. Set lazy.nvim configuration with the following config:
     require("lazy").setup(plugins, {
       install = {
         colorscheme = { "tokyonight" },
       }
     })
  3. Ensure you have installed tokyonight
  4. Adding a new plugin folke/which-key.nvim
  5. Reopen neovim to trigger installing on startup
  6. You will see the floating windows' bg is not black as expected.

Expected Behavior

Colorscheme loaded with the user defined config and should not load twice.

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",
    lazy = false,
    priority = 1000,
    config = function()
      require("tokyonight").setup()
      vim.cmd.colorscheme("tokyonight")
      vim.api.nvim_set_hl(0, 'NormalFloat', { bg='#FFFFFF' })
    end
  }
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
  install = {
    colorscheme = { "tokyonight" },
  },
})
@leonasdev leonasdev added the bug Something isn't working label Feb 4, 2023
@leonasdev leonasdev changed the title bug: If load colorscheme when installing will set colorscheme twice bug: Load colorscheme when installing will set colorscheme twice Feb 4, 2023
@Susensio
Copy link

Susensio commented Feb 7, 2023

@leonasdev Did you managed to fix this? I'm having the same issue with colorschemes and modified highlights.

@folke
Copy link
Owner

folke commented Feb 7, 2023

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.

@folke folke closed this as not planned Won't fix, can't repro, duplicate, stale Feb 7, 2023
@Susensio
Copy link

Susensio commented Feb 7, 2023

Hey @folke , the thing is after installation the custom highlights in colorscheme plugin are not being applied.
Also, how can the temporal colorscheme be loaded if the plugin itself is not loaded? I guess I don't understand the loading order here.
The real question, I guess, is how can I set a complex function as a temporary colorscheme for lazy.vim? That way I could wrap my colorscheme + custom highlights an apply them as a whole.

As a side note, thank you for lazy.vim, I just migrated from packer and this is another level. Master work

@folke folke reopened this Feb 7, 2023
@folke
Copy link
Owner

folke commented Feb 7, 2023

I see what's happening here. During installation, we do colorscheme tokyonight. Since that plugin wasn't yet loaded, it will load the plugin during ColorSchemePre and execute its config() method. Your config() method will also run colorscheme tokyonight and set your custom highlights. After that the regular colorscheme call will run, but that obviously won't run your config again.

It's the same as doing colorscheme tokyonight twice. The first time will load the colorscheme, run its config. The second time you run colorscheme tokyonight, then the plugin is already loaded, so its config won't be ran anymore.

@folke folke closed this as completed in 49b43de Feb 7, 2023
@folke
Copy link
Owner

folke commented Feb 7, 2023

Should be fixed now

@folke
Copy link
Owner

folke commented Feb 7, 2023

Regardless, its always advised to do any custom changes in a ColorScheme autocmd. That would also have worked in this case.

@Susensio
Copy link

Susensio commented Feb 8, 2023

Regardless, its always advised to do any custom changes in a ColorScheme autocmd. That would also have worked in this case.

Oh I see, I did not know that was the way.
I did what you say but it is not working as expected. I've put all my custom highlights in a autocmd, which is called on plugin init. This is my code:

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 guess that init is being called after, thus the autocmd is not present at the time of setting the colorscheme.

I know I could manually move the fix_monokai function outside Lazy, but it makes sense to me that it should be kept within the plugin specs.

What would be the proper Lazy way of doing this?

@folke
Copy link
Owner

folke commented Feb 8, 2023

Just move it to the beginning of your config method

@leonasdev
Copy link
Author

Should be fixed now

It works perfectly now!! Thank you for your help❤️❤️

@Susensio
Copy link

Susensio commented Feb 9, 2023

Just move it to the beginning of your config method

Thanks, It works now.

Anyhow, shouldn't init always be called before config?

@unphased
Copy link

unphased commented Feb 22, 2023

Is there a reason why defining an after/plugin/<colorscheme-plugin-name>.vim will not run at the right time? I got it to run but it runs too early...

I have also not found a way to make the autocommand work. It works on old style colorschemes, but not on plugin style colorschemes loaded with lazy.

The colorscheme in question is glepnir/zephyr-nvim

At the top of my init.lua:

vim.cmd([[

  function! Adjust_colors()
    echom "adjusting colors"
    hi MatchParen gui=NONE guifg=NONE guibg=#504050
    hi CursorWord guibg=#404050 cterm=NONE gui=NONE
  endfunction
  autocmd ColorScheme zephyr call Adjust_colors()

]])

In the plugins.lua, at the top:

return {
  {
    'glepnir/zephyr-nvim',
    lazy = false,
    priority = 1000,
    config = function ()
      vim.cmd([[
        colorscheme zephyr
      ]])
    end
  },

With a code modification in /Users/slu/.local/share/nvim/lazy/zephyr-nvim/lua/zephyr.lua:
image

Upon starting nvim:

image

correct order observed

and yet STILL:

:hi CursorWord
CursorWord     xxx cterm=underline gui=underline guibg=#3f444a
Press ENTER or type command to continue

my overriding style failed to take effect. I can manually call Adjust_colors() to make it override. Please help.

In case it's relevant, the lazy loading code is:

-- init lazy.nvim plugin loader
local lazypath = vim.fn.stdpath("data") .. "/lazy/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)

-- plugins
require("lazy").setup("plugins", {
  change_detection = {
    -- automatically check for config file changes and reload the ui
    enabled = true,
    notify = true, -- get a notification when changes are found
  },
})

@unphased
Copy link

unphased commented Feb 22, 2023

OK -- the problem I was having was in the use of

config = function ()
      vim.cmd([[
        colorscheme zephyr
      ]])
    end

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.

After deleting that and collecting the autocommand definition and colorscheme setting command into one vim block and putting it after the lazy setup, I'm all good now. Still not working...

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants