Color scheme change at runtime is messy

[vabatta]

Changing with the color scheme leave behind some plugins to not update their colouring correctly during runtime. For example, switching from "Mocha" to "Latte" breaks the colouring in the Alpha plugin and the notify plugin flash the wrong color on notification.

I was using the same set of plugins in LazyVim and dynamically changing the colorscheme during runtime by polling my system theme (https://github.com/sheharyarn/werewolf.nvim) and had no issue.

What could be the problem?

[vabatta]

It seems that the culprit for notify.lua, removing it makes it work.

nvimdots/lua/modules/configs/ui/notify.lua

Line 26 in 7df41c4

background_colour = colors.base,

background_colour = nil,

[vabatta]

And remove the default set of the flavour of Catppuccin in

nvimdots/lua/modules/configs/ui/catppuccin.lua

Line 6 in 7df41c4

flavour = "mocha", -- Can be one of: latte, frappe, macchiato, mocha

flavour = nil, -- Can be one of: latte, frappe, macchiato, mocha

And adding the following after the other autocmd

nvimdots/lua/modules/configs/ui/alpha.lua

Lines 158 to 164 in 7df41c4

	vim.api.nvim_create_autocmd("User", {
	pattern = "LazyVimStarted",
	callback = function()
	dashboard.section.footer.val = footer()
	pcall(vim.cmd.AlphaRedraw)
	end,
	})

vim.api.nvim_create_autocmd("ColorScheme", {
	group = vim.api.nvim_create_augroup("AlphaColorScheme", { clear = true }),
	pattern = "*",
	callback = function()
		require("modules.utils").gen_alpha_hl()
		pcall(vim.cmd.AlphaRedraw)
	end,
})

[vabatta]

@ayamir Wouldn't these changes need to be in the actual modules and not in user land? With settings.lua I cannot override a value with a nil because they are merged via vim.tbl_extend("force", left, right) which do not account for nil values on either sides.

In user land this can be implemented as the following, so it's just stylistic as it forces me to use a function:

return function(defaults)
	defaults["flavour"] = nil

	return defaults
end

[vabatta]

Maybe only the autocmd can be implemented in core as it would fix the Alpha redraw.

[ayamir]

@ayamir Wouldn't these changes need to be in the actual modules and not in user land? With settings.lua I cannot override a value with a nil because they are merged via vim.tbl_extend("force", left, right) which do not account for nil values on either sides.

In user land this can be implemented as the following, so it's just stylistic as it forces me to use a function:

return function(defaults)
	defaults["flavour"] = nil

	return defaults
end

Firstly, your solution can be merged as a bug fix for the wrong behavior of mentioned plugins (notify, alpha) when changing ColorScheme.
Secondly, we use direct assignment operation instead of vim.tbl_extend("force", left, right) when merging user config for each plugin:
https://github.com/ayamir/nvimdots/blob/main/lua/modules/utils/init.lua#L252-L270
You can create a config file to override the default config as we stated in wiki: https://github.com/ayamir/nvimdots/wiki/Usage#steps-to-modify-plugin-configs, instead of trying to achieve it by modifying settings.lua.

[vabatta]

I think the root cause of these issues is that some plugins are controlled by hardcoded values at initialization, not by highlighting groups, which is why they don't support dynamic text color adjustment. But I remember that recently both alpha and notify have all been converted to a coloring scheme based on highlight groups, so IMO we should change all colors to dynamic registration within augroup __builtin_palette, rather than manually setting autocommands for each individual plugin.

This solution seems reasonable to me given alpha and notify can use the actual dynamic colors if they got an update that let them support it. I would like to have a look at those plugins' implementations to understand if the dynamic color picking is actually working (as seen that dynamic color switching with solely the vim.o.background would not update everything e.g. lualine).

Maybe we could consider using vim.NIL to represent this special case? It's a user object, so it won't be garbage collected.

I'm not entirely sure on why a nil there cannot be forced, but either way by having a look at Catppuccin init.lua setting a flavour in the setup options forces Catppuccin to ignore the background option.

Jint-lzxy/nvim lua/catppuccin/init.lua#L112C1-L118

local function get_flavour(default)
  local flavour
  if default and default == M.flavour and vim.o.background ~= (M.flavour == "latte" and "light" or "dark") then
    flavour = M.options.background[vim.o.background]
  else
    flavour = default
  end
  -- ...
  return flavour or M.options.flavour or vim.g.catppuccin_flavour or M.options.background[vim.o.background]
end

@Jint-lzxy IMO it should not be forced in the first place, meaning removing flavour = ... from modules and having Catppuccin chose using the background option (which would effectively mean mocha as the default background is set to dark).

nvimdots/lua/core/settings.lua

Line 77 in 7df41c4

settings["background"] = "dark"

nvimdots/lua/modules/configs/ui/catppuccin.lua

Line 7 in 7df41c4

background = { light = "latte", dark = "mocha" },

[Jint-lzxy]

I would like to have a look at those plugins' implementations to understand if the dynamic color picking is actually working.

afaict it's indeed working. For notify, we can now set background_colour to a custom hl group, like NotifyBackground. And alpha also has its own dedicated hl groups (i.e., Alpha*). I think what we're missing now is probably to register them to the __builtin_palette augroup and refresh them along with the colorscheme.

... (as seen that dynamic color switching with solely the vim.o.background would not update everything e.g. lualine).

Hmm I can't seem to reproduce this on my end. I tested it by typing :set background=(another variant), then switching back to the original background config. catppuccin did set the corresponding variant correctly based on the active background setting, and since we've also set up an autocommand for lualine, I don't think the issue is likely to come from here. Did I miss anything?

btw, since u mentioned werewolf.nvim, would u mind pasting ur on_change function here? Sometimes setting background before the colorscheme finishes initializing won't trigger the on_change part of the active scheme. I'm wondering if the problem could be coming from there.

IMO it should not be forced in the first place, meaning removing flavour = ... from modules and having Catppuccin chose using the background option (which would effectively mean mocha as the default background is set to dark).

💯 Agreed! I think I forgot to remove this line when catppuccin implemented o:background support. I'll definitely include that when we roll out a fix for this issue :D

[vabatta]

For notify, we can now set background_colour to a custom hl group

Looks to me this is then solvable with little effort since the support is there.

Hmm I can't seem to reproduce this on my end.

With the command :set background=(another variant) it actually works and by having a look at werewolf.nvim code, is probably because as you mentioned the background is likely to change before the colorscheme finishes initialising.
The culprit is likely to be that despite run_on_start is false, it would be polled right after .5s anyway which might still be before colorscheme finishes initialising (even if it looks odd to me seen the startup time being less than that).

Reference for the on_change function used.

on_change = function (system_theme)
	if system_theme == "Dark" then
		vim.opt.background = "dark"
	else
		vim.opt.background = "light"
	end
end

I honestly don't like the implementation of polling every .5s for theme changes, so for the moment I'm not using the plugin but rather use a settings.lua with recognition of the theme at startup.

settings.lua

local system_theme = function()
	local command = "defaults read -g AppleInterfaceStyle 2>/dev/null"
	local handle = io.popen(command)
	local result = handle:read("*a"):gsub("%s", "")
	handle:close()

	if result:match("Dark") then
		return "dark"
	else
		return "light"
	end
end

settings["colorscheme"] = "catppuccin"
settings["background"] = system_theme()

[Jint-lzxy]

even if it looks odd to me seen the startup time being less than that

When there's an up-to-date compiled cache, catppuccin will lazy-load just about everything (since all it needs to do at startup is source the corresponding Lua Bytecode). In other words, the other components of catppuccin are loaded into the main state after a bit of time. I've set the refresh period to 3000, and catppuccin is working just as expected.

I honestly don't like the implementation of polling every .5s for theme changes, so for the moment I'm not using the plugin but rather use a settings.lua with recognition of the theme at startup.

Thanks for the extra info! I'll be working on this in the next few days and use this snippet for testing.

[vabatta]

Implemented in #1152. Cheers!