About background

[Saafo]

Personally I used to make my editors and other softwares' colorscheme(background) to follow system. So do I hope to implement this in neovim.

Currently I'm using vim-lumen to fix correct background on startup, and subscribe to the system colorscheme change.

It works well until I found it costs about 30ms each time to startup. I want make it lazy loaded, but found many problems that I cannot solve by myself, so I want to discuss and get help from the community:

At first, I try to make vim-lumen to be lazy loaded by: lazy = true, event = "VeryLazy". Then I found a strange UI in Bufferline and Lualine like (no tint color!):

1. I did some research and found that without vim-lumen you can also reproduce with add some code in load_core in lua/core/init.lua:(make sure your system colorscheme is light. I'm using macOS 13.2.1)

This is normal:

	local colorscheme = require("core.settings").colorscheme
	vim.api.nvim_command("colorscheme " .. colorscheme)
	vim.cmd("set background=light")

But this is abnormal(You will see the bufferline and lualine become abnormal from normal suddenly:

	local colorscheme = require("core.settings").colorscheme
	vim.api.nvim_command("colorscheme " .. colorscheme)
	vim.api.nvim_create_autocmd("CursorHold", {
		once = true,
		callback = function(ev)
			vim.cmd("set background=light")
		end,
	})

And this is normal again:

	local colorscheme = require("core.settings").colorscheme
	vim.api.nvim_command("colorscheme " .. colorscheme)
	vim.api.nvim_create_autocmd("CursorHold", {
		once = true,
		callback = function(ev)
			vim.defer_fn(function()
				vim.cmd("set background=light")
			end, 1)
		end,
	})

It's quite odd and I really don't have any ideas of how this happened and how can we avoid it.

2. Then I found an option you can disable the startup fix in vim-lumen by adding vim.g.lumen_startup_overwrite = 0 in options.lua, equally you won't exec set background=light during lazy events callback like CursorHold or VeryLazy.

I tried start vim (with or without --clean) and nvim with --clean in system light or dark mode in Warp or iTerm2, it can set background correctly since I asked it with set background? and it can answer me correctly. So it proved that vim is able to know the system's colorscheme(background) at startup(although it can't be automatically changed if the system colorscheme changed)

So I think, okay, I'll use the vim's builtin startup detection and vim-lumen to detect system's colorscheme change.

I added vim.g.lumen_startup_overwrite = 0 in options.lua, and make vim-lumen loaded in VeryLazy(and do not set vim background in init.lua!). It works well but when I:

1. enter nvim again in lazygit in nvim by space + g in Warp
2. or simply start nvim in iTerm2 in system's light mode

The color is quite odd and I found set background? is dark! I really don't have any ideas again.....

3. Then I think, maybe it's related to catppuccin, and I add a debug message in it's load() function, and found a quite interesting thing:

In the Warp case, two messages will print, first dark, then back to light

In the lazygit case and iTerm2 case, one message will print, only dark

Now I doubt maybe some plugin in this repo's config cause this problem. But I'm not really familiar with them and want to ask for your help.

[CharlesChiuGit]

For the lazygit part, did u set lightTheme to false in lazygit config?

[Saafo]

I use default theme:

gui:
  showIcons: true
  expandFocusedSidePanel: true
git:
  paging:
    colorArg: never
    pager: delta --"$(defaults read -globalDomain AppleInterfaceStyle &> /dev/null && echo dark || echo light)" --paging=never
    useConfig: false
  parseEmoji: true
promptToReturnFromSubprocess: false

[CharlesChiuGit]

hmmm, if that's the case, I might not have any idea on how to fix this, sorry.

[ayamir]

Why set background? just use colorscheme catppuccin-<flavor> fine.

[Saafo]

I need somehow to detect the current system scheme when startup to decide which flavor I'll use. I can use defaults read -g AppleInterfaceStyle for sure, but it will costs about 30~40ms. So I wonder whether there's a way to get system scheme with low cost, like the pure (n)vim's builtin background attributes at startup.

[ayamir]

So it proved that vim is able to know the system's colorscheme(background) at startup(although it can't be automatically changed if the system colorscheme changed)

Does it mean:

local background = vim.o.background
if background == "dark" then
    vim.api.nvim_command("colorscheme catppuccin-mocha")
else
    vim.api.nvim_command("colorscheme catppuccin-latte")
end

If so, you should comment these lines:

nvimdots/lua/core/init.lua

Lines 161 to 164 in b5cde33

	local colorscheme = require("core.settings").colorscheme
	local background = require("core.settings").background
	vim.api.nvim_command("set background=" .. background)
	vim.api.nvim_command("colorscheme " .. colorscheme)

[Saafo]

If so, you should comment these lines:

I'm already comment these lines as my code examples at the very beginning of this post. However, I met some problems:

1. The vim.o.background is not available at the very beginning. I tried add the following code to init.lua and commented the original require("core"):

if not vim.g.vscode then
	-- require("core") -- comment this
end
print(1, vim.o.background)
vim.api.nvim_create_autocmd("VimEnter", {
	-- vim.api.nvim_create_autocmd("CursorHold", { -- same as "VimEnter"
	once = true,
	callback = function(ev)
		print(2, vim.o.background)
		vim.o.background = vim.o.background
		vim.defer_fn(function()
			print(3, vim.o.background)
			-- vim.o.background = vim.o.background
		end, 1000)
	end,
})

And the result will be(in both warp and iTerm):

1 dark
2 light
3 light

And I tried to keep require("core"), the result will be:

1 dark
2 dark
3 dark

I tried to comment vim.api.nvim_command("colorscheme " .. colorscheme) because catppuccin seems will affect the background, and this time the result is not stable:

in Warp and Terminal it's always dark light light, But in iTerm2(3.5.0beta10, because iTerm support follow system since 3.5) and in lazygit in warp, sometimes it's dark light light, and sometimes it's dark dark dark.

I'm curious about when vim.o.background will work and how it is assigned value. I tried to read vim's source code but I lost myself in it...

[Saafo]

2. I tried to assign value to vim.o.background in init.lua in warp (since it's temporarily work, though I've no idea how it works lol) and found the problem I've mentioned: colors in lualine and bufferline will become odd if I set vim.o.background in callback of events like VimEnter or CursorHold.

If I set a delay by vim.defer_fn, the problem gone, but I think it's ugly and tricky, and unexplainable.

[Jint-lzxy]

@Saafo There're a few somehow unrelated confusions in your question, so I'll start with the terminal emulators (the "parent" programs), and move out from there:

First let's take a look at the description of 'background' in options.txt (note the sections surrounded by ~~~)

							*'background'* *'bg'*
'background' 'bg'	string	~~~ (default "dark") ~~~
			global
	When set to "dark" or "light", adjusts the default color groups for
	that background type.  The ~~~ |TUI| or other UI ~~~ sets this on startup
	(triggering |OptionSet|) ~~~ if it can detect the background color. ~~~

	This option does NOT change the background color, it tells Nvim what
	the ~~~ "inherited" (terminal/GUI) background ~~~ looks like.
	See |:hi-normal| if you want to set the background color explicitly.
	.......

Personally don't want this reply to become a technical summary, so the following descriptions only provide summaries for those implementations. For the "dirty" implementation details, please refer to the objc or c code of the corresponding repos.

As described in the doc, whether nvim knows the appearance that the user is using directly depends on its parent process (usually the terminal emulator). The reason why 'background' is set to dark in iTerm2 and nvim/other "spawned" terminals is not because it is set to dark, but because it is the default value / fallback inherited value for this option. In fact, neither iTerm2 nor those "spawned" terminals correctly informed nvim of the relevant settings. For iTerm2, this is because iTerm2 itself didn't even take this into consideration and you would get stable random values (commit edee15f7); For other "spawned" terminals, this is because they're all pseudo-terminals - e.g., by carefully examining lazygit's commands, you will notice that lazygit is not directly calling git (or other commands), but executing the relevant commands in a new process (usually bash). In such cases, it is thus difficult to ensure that user configuration can be fully inherited. That's why:

1. enter nvim again in lazygit in nvim by space + g in Warp
2. or simply start nvim in iTerm2 in system's light mode

The color is quite odd and I found set background? is dark! I really don't have any ideas again.....

Next, you must not lazy-load vim-lumen, or it must be loaded before all plugins (well, except itself and lazy.nvim) b/c "setting 'background' will cause the color scheme to be reloaded" (:h g:colors_name), and in many events, multiple plugins will be loaded, with several highlight groups being set, and several global settings rewritten. So it would be difficult to anticipate what exactly happened within that event loop (you don't know what happened during the reload). Another important factor that leads to this issue is auto-session. It will remember many things, including user options. That is to say, it will set your background when restoring the current session. Then, your colorscheme becomes a mess due to the combination of these factors.

The simplest fix is to not lazy-load vim-lumen and let vim-lumen hijack your environment - in fact, 30ms is extremely difficult to perceive. No need to spend so much time on this trivial timing improvement :) You can also adjust the configs of (and options related to) auto-session, but it's up to you to decide what auto-session should store to achieve the desired effect. I personally prefer the former b/c writing more efficient code is far more advantageous than saving a few milliseconds per startup 😄

[Saafo]

Really thanks for your sweet detailed answer, learned a lot from it!! And I think the suggestion is constructive and acceptable, really thanks again for your reply!

[CharlesChiuGit]

omg, learned a lot too.