Bug: `lsp_workspace_symbols` Not Working, but `lsp_live_workspace_symbols` Works as Expected

[shricodev]

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

fish

Neovim version (nvim --version)

NVIM v0.10.4

Fzf version (fzf --version)

0.60.3

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

--height=50% --layout=default --border --color=hl:#2dd4bf

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({
-- I have only configured keymaps and nothing else.
-- Nothing interesting to add here.
})

Describe the bug / steps to reproduce

lsp_workspace_symbols method always returns

[Fzf-lua] No workspace symbols found

But that is indeed not the case as I am attached to a language I have configured LSP and all that. But lsp_live_workspace_symbols work like a charm.

I have attached this quick demo video:

Screencast.From.2025-03-14.23-37-34.mp4

and I am on the latest version of fzf-lua

    ● fzf-lua 12.18ms  <leader>fk
        dir    /home/shricodev/.local/share/nvim/lazy/fzf-lua
        url    https://github.com/ibhagwan/fzf-lua
        branch main
        commit 39ac9c7

[ibhagwan]

This isn’t a bug, some LSP’s wont return anything on workspace symbols unless a query is specified (which is sent with the “live” version).

For example gopls requires a query but lua_ls doesn’t.

[shricodev]

@ibhagwan, but wouldn't that be worth mentioning to the README? Many folks might feel that the lsp_workspace_symbols function does not work properly and may not know that lsp_live_workspace_symbols is the way to go.

[ibhagwan]

Not everything can be overloaded on the poor README, especially when this is somewhat LSP specific, a lot of the functionality requires some understanding of the underlying tech.

The Wiki is open edit if you wish to amend that.

[savchenko]

Confirmed to be the case with basedpyright. Resets syntax as well (?)

Added a Wiki note.

[ibhagwan]

Confirmed to be the case with basedpyright. Resets syntax as well (?)

Added a Wiki note.

Ty @savchenko!