'Invalid buffer id' when navigating too fast upwards
andrewferrier-ibm opened this issue · 5 comments
(I am not sure if this is related to #12. The errors are similar but not the same so I thought I'd keep it separate for clarity).
I see this style of error quite a lot when navigating around using dirbuf.nvim
:
Error executing vim.schedule lua callback: ...ck/packer/start/plenary.nvim/lua/plenary/async/async.lua:14: The coroutine failed with this mess
age: ...r/neovim/0.6.1/share/nvim/runtime/lua/vim/diagnostic.lua:51: Invalid buffer id: 4
stack traceback:
[C]: in function 'error'
...ck/packer/start/plenary.nvim/lua/plenary/async/async.lua:14: in function 'callback_or_next'
...ck/packer/start/plenary.nvim/lua/plenary/async/async.lua:40: in function <...ck/packer/start/plenary.nvim/lua/plenary/async/async.l
ua:39>
The buffer id itself varies, but otherwise the error is the same stacktrace.
The strange thing is that whether it appears seems to depend on how fast I navigate around! I can recreate it like this:
- Open NeoVim with any file:
nvim ~/.some/relatively/deeply/nested/file
- Navigate upwards rapidly by pressing
-
several times in quick sequence. 2-3 times seems to produce the error.
If I deliberately slow down (e.g. leave a delay of >0.5s between -
keypresses), the error does not occur.
Because I tend to move around quite fast, this gets annoying after a while!
I know this sounds strange, but I can reproduce it fairly reliably on my system. I haven't yet tried to reproduce it with a minimal configuration but happy to try that if it would help.
In case this helps, I have done a git bisect
, since this problem didn't occur until recently. Looks like this problem was introduced by this commit
commit 7cdcd19324c93b90e7c2bf35e59680c174abac62
Author: Eli W. Hunter <elihunter173@gmail.com>
Date: Thu Jan 27 21:46:06 2022 -0500
Set bufhidden=wipe
lua/dirbuf.lua | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
If I checkout the commit before this, the problem disappears.
This is interesting since the error message is coming from plenary.nvim
's async.lua
, but Dirbuf doesn't use plenary. I suspect the issue is there is some autocommand or background task running when a dirbuf buffer is being opened / is open. So when you navigate quickly, the directory buffers are getting deleted before that background task finishes running (since bufhidden=wipe
deletes buffers when you hide).
Is there any plugin or part of your config that you would suspect is doing something like this? I can't seem to replicate this with a minimal config or my personal config
Apologies, this was totally my fault, and you're quite right, it's not in dirbuf
- the issue was in null-ls
, which uses plenary
. Just in case others come across the same issue:
I have a custom null_ls
source which applies to almost every buffer which checks for trailing spaces. It had a list of disabled_filetypes
which included d
, the filetype that vinegar seems to use. However, when I switched to dirbuf
, I obviously forgot to change this over. Adding "dirbuf"
to the disabled_filetypes
list for that source fixed it.
Thanks again for the clues and sorry for taking up your time on an issue which wasn't dirbuf's!
I think you can close this issue, FWIW :)
Happy to help!