Bug: `FzfLua lsp_document_symbols` doesn't work with the in-memory LSP used in `vim.pack.update()`'s confirmation buffer

[TheLeoP]

RTFM Checklist

• I have searched exisiting issues / discussions
• I have read the Wiki including the Advanced section
• I have read man fzf / I am well versed in shell fzf

Operating system

Linux

Shell

zsh

Neovim version (nvim --version)

NVIM v0.12.1 Build type: RelWithDebInfo

Fzf version (fzf --version)

0.71.0 (62899fd7)

Output of :lua print(os.getenv('FZF_DEFAULT_OPTS'))

nil

Is the problem reproducible with mini.sh?

• My issue is reproducible with mini.sh
• My issue IS NOT reproducible with mini.sh
• I have not tested with mini.sh (not relevant, requires LSP, Windows, etc)

Fzf-lua configuration

require('fzf-lua').setup({})

Describe the bug / steps to reproduce

1. sh -c "$(curl -s https://raw.githubusercontent.com/ibhagwan/fzf-lua/main/scripts/mini.sh)"
2. :lua vim.pack.add({'https://github.com/ibhagwan/fzf-lua'}) (simply installing any plugin works)
3. :lua vim.pack.update()
4. While inside the confirmation buffer created by vim.pack, :FzfLua lsp_document_symbols. The picker will appear to be loading and nothing will be shown.

Manually executing :lua vim.lsp.buf.document_symbol() does work

[ibhagwan]

I’ll have to dig deeper, it seems the in memory LSP callback is never called back with async, it does work with :FzfLua lsp_document_symbols async=false

[ibhagwan]

Ok so the callback does come back with results but it happens before yield is called causing the yield to hang.

[phanen]

in-process lsp use callback but it's not real async.

[phanen]

We can schedule the request, to "make it async"

[phanen]

Or the callback:

diff --git a/lua/fzf-lua/providers/lsp.lua b/lua/fzf-lua/providers/lsp.lua
index c169878..9f551da 100644
--- a/lua/fzf-lua/providers/lsp.lua
+++ b/lua/fzf-lua/providers/lsp.lua
@@ -567,7 +567,7 @@ local function gen_lsp_contents(opts)
           -- when using `live_ws_symbols`
           _, opts._cancel_all = vim.lsp.buf_request(utils.CTX().bufnr,
             lsp_handler.method, lsp_params,
-            function(err, result, context, lspcfg)
+            vim.schedule_wrap(function(err, result, context, lspcfg)
               -- Increment client callback counter
               async_opts.num_callbacks = async_opts.num_callbacks + 1
               -- did all clients send back their responses?
@@ -580,7 +580,7 @@ local function gen_lsp_contents(opts)
                 end
               end
               coroutine.resume(co, done, err, result, context, lspcfg)
-            end)
+            end))
         end
 
         -- When called from another coroutine callback (when using 'finder') will err:

[ibhagwan]

We already use vim.schedule in fast even, can just remove the condi:

diff --git a/lua/fzf-lua/providers/lsp.lua b/lua/fzf-lua/providers/lsp.lua
index c169878f..d0da06ea 100644
--- a/lua/fzf-lua/providers/lsp.lua
+++ b/lua/fzf-lua/providers/lsp.lua
@@ -585,13 +585,9 @@ local function gen_lsp_contents(opts)

         -- When called from another coroutine callback (when using 'finder') will err:
         -- E5560: nvim_exec_autocmds must not be called in a lua loop callback nil
-        if vim.in_fast_event() then
-          vim.schedule(function()
-            async_buf_request()
-          end)
-        else
+        vim.schedule(function()
           async_buf_request()
-        end
+        end)

         -- process results from all LSP client
         local err, result, context, lspcfg, done

[ibhagwan]

Which approach do you like better, both are acceptable and work

[phanen]

#2654 (comment), since we don't need twice vim.schedule