How to handle many colorscheme and lazy loading at the same time?

[metalelf0]

Hi, I'm trying to figure out what's the best way to handle a setup with many colorschemes (let's say, 20 or more) to choose from. Right now, I found the following approaches.

Setup all of them with lazy = false, priority = 1000 and add a clause to the config() function to exit unless the colorscheme is the chosen one.

I have an user.config module and code like:

local config = require("user.config")

M.config = function()
	if config.colorscheme ~= "tokyonight" then
		return false
	end

       -- ... (omissis)
end

for each colorscheme.

This solution has the following pros/cons:

• pros: it allows to choose between all the colorschemes via :colorscheme and all of them are updated automatically via :Lazy;
• cons: no colorscheme is lazy loaded, so this has a big impact on startup performance.

Only load the chosen colorscheme and skip the others via enabled = false

This solution has the following pros/cons:

• pros: only the chosen colorscheme is loaded;
• cons: other colorschemes are not updated via :Lazy and are not chosable via :colorscheme.

(Not working) Load the chosen colorscheme with lazy = false and lazy load others with lazy = true

I hacked together some code to get this setup, expecting to get the pros of the two solutions above, without any cons. However, it seems that setting lazy = true for colorschemes is the same as setting them to enabled = false, and they aren't chosable via :colorscheme.

Other considerations / experiments

I think the way to go would be to add some sort of event = "ColorSchemePromptEnter", but I have no idea how to set this up. event = "CmdlineEnter" is the closest I could get, but obviously it's suboptimal.

Or maybe there's another way built-in into lazy.nvim that I still haven't found? Any suggestion / hint?

Thanks in advance!

[abeldekat]

You can keep all colorschemes enabled and lazy-loaded.

Personally, I choose the colorscheme using an external bash script for dmenu. If I want all colorschemes available from within Neovim, I temporarily set lazy=false using a module variable, and accept the overhead.

[dpetka2001]

In my case I have one colorscheme set as default (tokyonight) and the rest I lazy-load with keys handler like so

  {
    "rose-pine/neovim",
    name = "rose-pine",
    keys = {
      { "<leader>uC", Util.telescope("colorscheme", { enable_preview = true }), desc = "Colorscheme with preview" },
    },
  },

I use Lazyvim and Util is specified as local Util = require("lazyvim.util"), but you could achieve the same on your own config by just calling Telescope colorscheme and assigning that to a keymap. So, only tokyonight is loaded by default and the rest are lazy-loaded only when I press the keymap and want to change the colorscheme.

[alivault]

Oh, good to know. Much cleaner now, thank you

[abeldekat]

Having all colors inside one spec makes it possible to lazy load all colors without using an autocmd.

Example colors.lua:

local spec = {
  {
    "folke/tokyonight.nvim",
    name = "colors_tokyonight",
    lazy = true,
    config = function() vim.print("setup tokyo") end,
  },
  {
    "catppuccin/nvim",
    name = "colors_catppuccin",
    lazy = true,
    config = function() vim.print("setup catppuccin") end,
  },
  --          ╭─────────────────────────────────────────────────────────╮
  --          │                  More colorschemes....                  │
  --          ╰─────────────────────────────────────────────────────────╯
}

vim.keymap.set("n", "<leader>uu", function() --> Show all custom colors in telescope...
  for _, color in ipairs(spec) do  --> Load all colors in spec....
    vim.cmd("Lazy load " .. color.name) --> vim colorschemes cannot be required...
  end

  vim.schedule(function() --> Needs to be scheduled:
    -- stylua: ignore
    local builtins = { "zellner", "torte", "slate", "shine", "ron", "quiet", "peachpuff",
    "pablo", "murphy", "lunaperche", "koehler", "industry", "evening", "elflord",
    "desert", "delek", "default", "darkblue", "blue" }

    local completion = vim.fn.getcompletion
    ---@diagnostic disable-next-line: duplicate-set-field
    vim.fn.getcompletion = function() --> override
      return vim.tbl_filter(function(color)
        return not vim.tbl_contains(builtins, color) --
      end, completion("", "color"))
    end

    vim.cmd("Telescope colorscheme enable_preview=true")
    vim.fn.getcompletion = completion --> restore
  end)
end, { desc = "Telescope custom colors", silent = true })

return spec

When there are many colorschemes using event = "some-event", the startuptime can be a tiny bit slower. In the spec phase, lazy needs to process each individual event using its event handler.

When using lazy.config.defaults.lazy = true, all lines containing lazy=true can be removed.

Link to the config: colors.lua

[LunarLambda]

I believe lazy is smart enough to only register a single autocmd, but I suppose one could also just measure the difference in startup time to find out if it matters

[dpetka2001]

I believe it's more about the event handler having to be invoked for each spec during the spec phase (and create the necessary ids for each spec and anything extra it might create during the parsing that lazy needs to track). Not about the registering of the autocmd, which will probably be only one. But i don't believe it'll make such a big difference in the end. Just some small amount of milliseconds (probably not making it a problem for the user experience).

[abeldekat]

Lazy only registers a single autocmd. However, lazy must process event = "some-event" using its handler for each color spec.
In general one can say: In order for lazy loading to be setup, lazy needs to execute code during its spec phase at the cost of a little startuptime.

The solution I presented does not use that mechanism, thus being a little faster.

Quote from this comment

My argument is that using the autocmd trigger requires less "abstraction"/code to set up.

Indeed. Without the autocmd even less "abstraction/code" is needed.

[dssste]

Instead of setting the colorscheme in the config file, get the desired colorscheme name from either some persistent storage or some variable which you can access during start up.

-- read from txt, dumb but works
local function load()
	local file = io.open(vim.fn.stdpath('config') .. '/colorscheme.txt', 'r')
	if file then
		local name = file:read('*l')
		file:close()
		return name
	end
end

local name = load()
if name and name ~= '' then
	for _, spec in ipairs(specs) do
		if spec.name == name then
			spec.lazy = false
			spec.priority = 100
		else
			spec.lazy = true
		end
	end
end
return specs

Also if you'd like to change colorscheme mid-session, make yourself a custom command instead of the built in colorscheme command. You can do anything without having to think of how to use autocmd and such.

vim.api.nvim_create_user_command('Colorpencil', function(opts)
	save(opts.args) -- this function saves the value to txt
	for _, spec in ipairs(specs) do
		if spec.name == opts.args then
			spec.config()
			return
		end
	end
end, { nargs = 1 })

[folke]

not a lot of people know, but you can just use any global variable all uppercase.
Those are always saved in the shada.

So vim.g.TEST = 123.

[dssste]

Loved the idea, but it didn't work at first, maybe because init.lua runs before reading shada on start up (https://neovim.io/doc/user/starting.html#initialization.
Not sure if there are better ways but I added a vim.cmd('rshada'), and the end result is much cleaner than my txt solution.