fuzzy_finder not working

[gsalvatella]

Using the fuzzy_finder associated with the / key is not working. Either it doesn't find any matches or it often throws the following error:

Error executing luv callback:
cannot resume dead coroutine
stack traceback:
        [builtin#36]: at 0x7f53e35f1320
        [C]: in function 'wait'
        .../site/pack/packer/start/plenary.nvim/lua/plenary/job.lua:218: in function 'shutdown'
        .../site/pack/packer/start/plenary.nvim/lua/plenary/job.lua:343: in function <.../site/pack/packer/start/plenary.nvim/lua/plenary/job.lua:342>

Using the bare bones configuration provided by the current README.

[cseickel]

Do you have fd or find installed? If so, can you tell me what version you have?

[gsalvatella]

find --version
find (GNU findutils) 4.9.0

[cseickel]

I'm not able to recreate this issue. It is possible that it is a conflict with another plugin. Can you try a minimal init with just Neo-tree installed to see if the issue still exists?

[gsalvatella]

I have tried it as you mention (removing all other plugins) and the error persists. Screenshot while trying to look for "lua" with the fuzzy_finder. For now the solution for me is to deactivate it in the options (set to none).

[cseickel]

The only think I can think of is to make sure that plenary is up to date.

It's possible there might be some more clues in the logs: https://github.com/nvim-neo-tree/neo-tree.nvim/wiki/Troubleshooting

[gsalvatella]

Plenary is up to date and the logs do not show any particular issues...
A somewhat related problem was reported for telescope: nvim-telescope/telescope.nvim#549
I have tested it in a different terminal (alacritty) and the same error shows up...

[cseickel]

I'm thinking that there is just some error happening in the async task that is crashing it. Maybe I can look for places to add extra error handling. Can you post your logs so I can see how far it gets before the error?

[gsalvatella]

neotree.log

Seems to error out in the vim.wait function? Not sure what the builtin#36 part of the stack trace is signaling

[cseickel]

I got it! I saw in the log that there was a lot of permission denied errors. When I add a folder within my cwd that my user does not have permission to, I get the same error as you.

Now that I have recreated it, I'm sure I can fix it.

[cseickel]

I think the latest commit in main will work around this problem for you, given that you are on a recent version of fd. This is ultimately a bug in plenary though, and my fix will not help users that rely on the find command instead which does not have a built-in "max results" option.

I'll try to submit a fix to the plenary project as well to fix the underlying issue.

EDIT: Here's that bug report: nvim-lua/plenary.nvim#327

[cseickel]

I think the latest commit in main will work around this problem for you, given that you are on a recent version of fd.

I'm sorry, I forgot that you are using find and not fd. This will NOT work for you. It will if you install fd though, which is really a better search tool.

I'll also add in a workaround for find soon.

[gsalvatella]

Thank you big time for the fix! So it was indeed a bug in the vim.wait function. Good that it has been found. Let's see if they fix it up soon and you can revert these workarounds. For now I'm disabling it and finding with the standard vim /?, since telescope makes the job and I prefer to avoid non-gnu-utils dependencies when possible. From my side you can close the issue unless you prefer to wait until the upstream problem is fixed.

[cseickel]

Oh yeah, I forgot to update you, last night I added another workaround that supports all commands. You should be safe to use it with find now.

I'm not sure if the upstream plenary/nvim issue is going to be fixed anytime soon, so I'll probably just leave my workaround in place and close this issue. It will close automatically when I release it to v1.x, which will be later today.