I observed that when I preview files in a directory with a LSP that provides semanticTokens I get bombarded with such errors:
Error executing vim.schedule lua callback: ...local/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:309: ...local/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:102: Invalid buffer id: 32
stack traceback:
[builtin#36]: at 0x5a9e035cf470
...local/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:309: in function 'handler'
/usr/local/share/nvim/runtime/lua/vim/lsp/client.lua:687: in function ''
vim/_editor.lua: in function <vim/_editor.lua:0>
Error executing vim.schedule lua callback: ...local/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:309: ...local/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:102: Invalid buffer id: 33
stack traceback:
[builtin#36]: at 0x5a9e035cf470
...local/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:309: in function 'handler'
/usr/local/share/nvim/runtime/lua/vim/lsp/client.lua:687: in function ''
vim/_editor.lua: in function <vim/_editor.lua:0>
when I step through the files very slowly (and let the semantic tokens finish loading) I don't get such errors. Same as when I disable them from the LSP: server_capabilities = { semanticTokensProvider = vim.NIL }.
I noticed it with the clangd language server.
What is the severity of this bug?
breaking (some functionality is broken)
Steps To Reproduce
Use a LSP which provides semantic tokens. I used clangd
Open oil and preview the files (which the lsp recognizes) very quickly so that semantic tokens cannot finish loading
Expected Behavior
No error.
Directory structure
No response
Repro
-- Sorry, I don't have time for this. Either the issue is clear and easily reproducible with a LSP that supports semantic tokens or you can close it. I just want to report the issue
-- save as repro.lua
-- run with nvim -u repro.lua
-- DO NOT change the paths
local root = vim.fn.fnamemodify("./.repro", ":p")
-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "runtime", "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",
"--single-branch",
"https://github.com/folke/lazy.nvim.git",
lazypath,
})
end
vim.opt.runtimepath:prepend(lazypath)
-- install plugins
local plugins = {
"folke/tokyonight.nvim",
{
"stevearc/oil.nvim",
config = function()
require("oil").setup({
-- add any needed settings here
})
end,
},
-- add any other plugins here
}
require("lazy").setup(plugins, {
root = root .. "/plugins",
})
vim.cmd.colorscheme("tokyonight")
-- add anything else here
Did you check the bug with a clean config?
[X] I have confirmed that the bug reproduces with nvim -u repro.lua using the repro.lua file above.
Did you check the docs and existing issues?
Neovim version (nvim -v)
NVIM v0.11.0-dev-189+g78d3f4742
Operating system/version
ndeavourOS Linux x86_64
Describe the bug
I observed that when I preview files in a directory with a LSP that provides semanticTokens I get bombarded with such errors:
when I step through the files very slowly (and let the semantic tokens finish loading) I don't get such errors. Same as when I disable them from the LSP:
server_capabilities = { semanticTokensProvider = vim.NIL }
.I noticed it with the clangd language server.
What is the severity of this bug?
breaking (some functionality is broken)
Steps To Reproduce
Expected Behavior
No error.
Directory structure
No response
Repro
Did you check the bug with a clean config?
nvim -u repro.lua
using the repro.lua file above.