bug: Error when quickly previewing files with semantic tokens LSP capabilities.

[deeedob]

Did you check the docs and existing issues?

• [X] I have read the docs
• [X] I have searched the 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:

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

1. Use a LSP which provides semantic tokens. I used clangd
2. 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.

[daver32]

Seems to be a problem with code that does async things to buffers, without expecting them to be deleted in the meantime. I'm getting the same error with mini.hipatterns (https://github.com/echasnovski/mini.nvim/issues/1080). The repro I posted there gives me your error too if I use nightly.

TLDR: not an Oil issue from what I can tell

[jelmansouri]

Wondering if it's worth disabling the lsp and other functionnality on file previews by default. I believe telescope those that as I don't see sementic based coloring on its previews.

[jelmansouri]

Wondering if it's worth disabling the lsp and other functionnality on file previews by default. I believe telescope those that as I don't see sementic based coloring on its previews.

Tried to look around in telescope and trouble where only treesitter syntax highlighing is enabled but no luck, if you have an idea, I can do a PR.

Edit: the scratch option does this I think

--- Create a preview buffer for an item.
--- If the item has a loaded buffer, use that,
--- otherwise create a new buffer.
---@param item trouble.Item
---@param opts? {scratch?:boolean}
function M.create(item, opts)
  opts = opts or {}

  local buf = item.buf or vim.fn.bufnr(item.filename)

  if item.filename and vim.fn.isdirectory(item.filename) == 1 then
    return
  end

  -- create a scratch preview buffer when needed
  if not (buf and vim.api.nvim_buf_is_loaded(buf)) then
    if opts.scratch then
      buf = vim.api.nvim_create_buf(false, true)
      vim.bo[buf].bufhidden = "wipe"
      vim.bo[buf].buftype = "nofile"
      local lines = Util.get_lines({ path = item.filename, buf = item.buf })
      if not lines then
        return
      end
      vim.api.nvim_buf_set_lines(buf, 0, -1, false, lines)
      local ft = item:get_ft(buf)
      if ft then
        local lang = vim.treesitter.language.get_lang(ft)
        if not pcall(vim.treesitter.start, buf, lang) then
          vim.bo[buf].syntax = ft
        end
      end
    else
      item.buf = vim.fn.bufadd(item.filename)
      buf = item.buf

      if not vim.api.nvim_buf_is_loaded(item.buf) then
        vim.fn.bufload(item.buf)
      end
      if not vim.bo[item.buf].buflisted then
        vim.bo[item.buf].buflisted = true
      end
    end
  end

  return buf
end

[jelmansouri]

I can work further on this if it seems like the right thing: https://github.com/stevearc/oil.nvim/pull/467

[avario-cpu]

Makes the preview pretty much unusable for me rn, tried fixes with autocmds etc but havent found a satisfactory one yet

[MagicDuck]

Just an FYI that I encountered the same problem with grug-far preview recently and ended up working around it by using bdelete instead. Don't know too much about oil (just saw this issue when I was googling the error), but it might be an alternative 😄 way to address it. See this PR: https://github.com/MagicDuck/grug-far.nvim/pull/271/files