Worked Around: Telescope Invalid Window ID 10xx On Opening Large File: Disable `actions.open_file.eject`
Closed this issue · 6 comments
Description
Not sure if this is the right place for this bug. But I suspect NvimTree could be the problem.
When opening a file of ~ 1-2k lines on my machine using Telescope. The neovim treesitter api complains about invalid window ID. Which is the window ID of the NvimTree window. This leads to any long files not having syntax highlighting when using these plugins.
Neovim version
NVIM v0.11.2
Build type: RelWithDebInfo
LuaJIT 2.1.1748459687
Operating system and version
Linux 6.15.2-arch1-1
Windows variant
No response
nvim-tree version
v1.13.0
Clean room replication
vim.g.loaded_netrw = 1
vim.g.loaded_netrwPlugin = 1
vim.cmd([[set runtimepath=$VIMRUNTIME]])
vim.cmd([[set packpath=/tmp/nvt-min/site]])
local package_root = "/tmp/nvt-min/site/pack"
local install_path = package_root .. "/packer/start/packer.nvim"
local function load_plugins()
require("packer").startup({
{
"wbthomason/packer.nvim",
"nvim-tree/nvim-tree.lua",
"nvim-tree/nvim-web-devicons",
"nvim-lua/plenary.nvim",
"nvim-telescope/telescope.nvim",
"nvim-treesitter/nvim-treesitter",
-- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
},
config = {
package_root = package_root,
compile_path = install_path .. "/plugin/packer_compiled.lua",
display = { non_interactive = true },
},
})
end
if vim.fn.isdirectory(install_path) == 0 then
print("Installing nvim-tree and dependencies.")
vim.fn.system({ "git", "clone", "--depth=1", "https://github.com/wbthomason/packer.nvim", install_path })
end
load_plugins()
require("packer").sync()
vim.cmd([[autocmd User PackerComplete ++once echo "Ready!" | lua setup()]])
vim.opt.termguicolors = true
vim.opt.cursorline = true
-- MODIFY NVIM-TREE SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
_G.setup = function()
require("nvim-tree").setup({})
-- Setup treesitter as it contributes to the failure.
require'nvim-treesitter.configs'.setup {
ensure_installed = {
"lua",
},
sync_install = true,
highlight = { enable = true }
}
endSteps to reproduce
- nvim -nu /tmp/nvt-min.lua
- :NvimTreeOpen
- Run this to check the window id of the NvimTree buffer:
:lua for i = 1, vim.fn.winnr('$') do print('Window ' .. i .. ' ID: ' .. vim.fn.win_getid(i)) end - Move cursor to NvimTreeBuffer
- :Telescope find_files
- Choose a large file. Example: https://github.com/jzho987/nvim/blob/bug-setup/long.lua
- Jump to said file.
Expected behavior
Expected the file to correctly open, and syntax highlight to work. No errors should be thrown.
Actual behavior
Error gets thrown. Syntax highlighting no longer works.
Note the nvimtree window id should be the same as what was printed in the step 3
This is a bit frustrating for me, so just trying to track down the culprit. Happy to close this if it should be somewhere else instead.
Thanks for raising. It looks like it might be a race condition between telescope opening the file and nvim-tree ejecting long.lua from its window.
I'm not able to reproduce with a 200k line file, however I can see the window swapping happening briefly ~1sec.
This helps show which winids are used:
vim.opt.statusline = "b%{bufnr()} w%{winnr()} i%{win_getid()}"Before
After
You can see that the original tree window 1002 was deleted and 1007 was created.
Opening telescope from 1000 resulst in 1002 being retained.
Please try disabling ejection and see if the problem persists. The win ids should not change.
_G.setup = function()
require("nvim-tree").setup({
actions = {
open_file = {
eject = false
}
}
})You're using arch, as am I.
What file system?
Please try disabling ejection and see if the problem persists. The win ids should not change.
_G.setup = function() require("nvim-tree").setup({ actions = { open_file = { eject = false } } })You're using arch, as am I.
What file system?
Thanks a bunch for that! I will try with eject off soon and let you know if it fixes it. I am just using Ext4 for my system. If that is what you are asking?
Hey @alex-courtis I turned off eject, and I can see that issue is resolved. I think this should be good enough for my use case, so happy for you to close this. Not sure if this has further implications with other users? Thanks for the help tho, it is very valuable!
If you're happy with that, I don't think there's much more we can do. Diagnosing and fighting async event collisions between plugins is not achievable.
Telescope does sometimes have issues with its floating prompt windows, occasionally throwing invalid window errors.


