telescope.nvim

telescope.nvim copied to clipboard

Description

Calling lsp_workspace_symbol prompts an error.

Expected Behavior Normally enter the search.

Actual Behavior No results from workspace/symbol. Maybe try a different query: Telescope lsp_workspace_symb│ols query=example.

Details

Reproduce

1. nvim main.go
2. :Telescope lsp_workspace_symbols

Environment

• nvim --version output: NVIM v0.5.0 Build type: Release LuaJIT 2.1.0-beta3 Compilation: clang -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -O2 -DNDEBUG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/tmp/neovim-20210702-14987-rep9di/neovim-0.5.0/build/config -I/tmp/neovim-20210702-14987-rep9di/neovim-0.5.0/src -I/usr/local/include -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -I/usr/local/opt/gettext/include -I/tmp/neovim-20210702-14987-rep9di/neovim-0.5.0/build/src/nvim/auto -I/tmp/neovim-20210702-14987-rep9di/neovim-0.5.0/build/include
• Operating system: macos 11.4
• Telescope commit: 1dd6f84

Configuration

No telescope configuration

Try Telescope lsp_dynamic_workspace_symbol

You are likely using a language server that returns 0 results for an empty query.

Try Telescope lsp_dynamic_workspace_symbol

You are likely using a language server that returns 0 results for an empty query.

It's okay to use this, but the result is too much. it's all workspaces. Is there a solution to the current use of lsp_workspace_symbol?

If you run Telescope lsp_workspace_symbol query=symbol_name

Do you get the same results as the dynamic workspace symbol? (When you type in the same query).

I don't know the code-base that well, but when I read the implementation of dynamic_worksapce_symbol and workspace_symbol I can't see any difference.

I'm assuming that your language server is returning results for all workspaces...

Which language are you using, and which language server?

If you run Telescope lsp_workspace_symbol query=symbol_name

Do you get the same results as the dynamic workspace symbol? (When you type in the same query).

I don't know the code-base that well, but when I read the implementation of dynamic_worksapce_symbol and workspace_symbol I can't see any difference.

I'm assuming that your language server is returning results for all workspaces...

Which language are you using, and which language server?

Yes, use lsp_workspace_symbol query=marshal and lsp_ dynamic_workspace_symbol, and then search for marshal, and get many results that are not in the current workspace.

I use go and gopls as LSP.

Is this still happening?

I face a similar problem with jdtls - no results being shown. Trying to use lsp_dynamic_workspace_symbols is really slow because a query is performed on each keypress and 'cancel' function doesn't really seem to do anything, at least not immediately, as a result searching for a 'get' will perform one full query for 'g' and then another one with 'get', but the first one completes for around 5-10 seconds on a medium sized java project with 20 libraries.

So one thing that could improve this is either to allow workspace_symbol to show even if initially there are no results from the lsp, and then to type the query and manually trigger it, effectively performing Telecope workspace_symbol query=example (although this doesn't look like it will fit easily with the other pickers behavior), or at least have an option for a min query length in lsp_dynamic_workspace_symbol so it will skip those one letter queries that don't make much sense in most cases.

Hi, I get no results using Telescope lsp_dynamic_workspace_symbol . Those are python files and I have pyright. vim-aerial does work and presents current file symbols.

I have a similar issue. When using :Telescope lsp_workspace_symbols with either jedi-language-server or pyright I get this:

When trying to use :Telescope lsp_dynamic_workspace_symbols I get an error:

Using the built-in vim.lsp.buf.references() works just fine -- it opens the quickfix menu with results from multiple files. This leads me to believe that the issue could be with Telescope?

I have the same issue,I get no results using :Telescope lsp_dynamic_workspace_symbols, I use the pyright and gopls

Same issue here, I have pyright and vim.lsp.buf.document_symbol() displays a correct list, but :Telescope lsp_workspace_symbols with a query displays an empty list. In a lua file Telescope works correctly. Maybe a change in pyright ?

Edit : :Telescope treesitter displays an empty list as well.

Edit 2 : solved for me. It was kind of simple… In the telescope setup I had a file_ignore_patterns with .git and my code was in a ~/git/project/ directory. I changed the ignore pattern and now everything is fine.

The lsp_dynamic_workspace_symbols used to work for me but is broken since I updated to neovim 0.8 for typescript at least. lua files work fine though. It gives the same error as described here https://github.com/nvim-telescope/telescope.nvim/issues/964#issuecomment-1200157618

Calling :lua vim.lsp.buf.workspace_symbol() works as expected and accepts a second value Query: after calling. You can also call it with an argument to open it directly in the quickfix panel. So this appears to be a telescope issue.

Turns out this is happening when I enable both grapqhl and tsserver lsp on typescript files, which I need to do because my graphql queries are defined in typescript files with the gql template literal.

I needed to disable the client.server_capabilities.workspaceSymbolProvider for graphql lsp to make this work again. Because both lsp attach to typescript buffers and apparently break the dynamic workspace symbols function. It would be great to add some documentation about this, probably in the graphql lsp docs.

What I did was basically this:

require('lspconfig).graphql.setup {
  on_attach = function(client)
    client.server_capabilities.workspaceSymbolProvider = false
  end,
  filetypes = {
    "graphql",
    "typescriptreact",
    "typescript",
    "javascript",
    "javascriptreact"
  },
}

I am not sure if this is the right place for this issue, but maybe it will solve issues for anyone else here too, since it took me a very long time to investigate this. Hope it helps anyone!

Telescope lsp_dynamic_workspace_symbols appears to work with pyright, insofar I get a list of symbols in the workspace. It seems to be in a format that's not very useful though, namely what appears to be a list of tab separated rows with the file name, symbol name, and symbol type (variable, function, etc). Telescope matches on the entire line, which isn't that useful.

I don't think you can configure the output format for pyright. Is this something Telescope can parse?

lsp_dynamic_workspace_symbols doesn't work for me: it gives me an empty screen.

However, you can get a prompt for a query and use that for lsp_workspace_symbols:

vim.keymap.set("n", "<leader>fS", function()
        vim.ui.input({ prompt = "Workspace symbols: " }, function(query)
                ts.lsp_workspace_symbols({ query = query })
        end)
end, { desc = "LSP workspace symbols" })

This asks for a query in the command-line and opens a Telescope with the results.

I have a similar issue when using clangd. Here are the steps to reproduce.

1. Create a directory for the project and move there.
2. Create a header file header.h:

struct S
{
    int m;
};

3. Create a source file

#include "header.h"

int main()
{
    return 1;
}

4. Open the source file in nvim.
5. Open the Telescope lsp_workspace_symbols interactive prompt and type S. NOT FOUND.
6. Run :Telescope lsp_workspace_symbols query=S. FOUND.

And here's another thing I noticed:

7. Open the header file in a second buffer.
8. Open the Telescope lsp_workspace_symbols interactive prompt and type S. FOUND.

@rjurga I tried these steps but in step 5, I can find S not sure that's going on. I'm on telescope master branch, neovim nightly. maybe that makes a difference.

Thanks for trying it out. I upgraded to make sure, and I still have the issue. Here are my versions:

• Neovim: v0.10.0-dev-09a17f9
• Telescope: 7d5195085 (master)
• clangd: 16.0.0
• OS: Windows 11 (if it makes any difference)

Here is my init.vim. I copy the relevants part here:

call plug#begin(stdpath('data') . '/plugged')
Plug 'neovim/nvim-lspconfig'
Plug 'nvim-lua/plenary.nvim' " Required for nvim-telescope
Plug 'nvim-telescope/telescope.nvim'
Plug 'nvim-telescope/telescope-fzf-native.nvim', { 'do': 'cmake -S. -Bbuild -DCMAKE_BUILD_TYPE=Release && cmake --build build --config Release && cmake --install build --prefix build' }
call plug#end()

local lspconfig = require('lspconfig')
lspconfig.clangd.setup {}

require('telescope').setup {
    defaults = {
        file_ignore_patterns = {
            "%.o",
            "%.obj",
            "%.a",
            "%.lib",
            "%.dll",
            "%.exe",
            "%.pdb",
            "%.sln",
            "%.vcxproj",
            "Session.vim",
        }
    }
}
require('telescope').load_extension('fzf')

local opts = { noremap = true, silent = true }
local builtin = require('telescope.builtin')
vim.keymap.set('n', '<leader>fs', builtin.lsp_workspace_symbols, opts)
vim.keymap.set('n', '<leader>fS', builtin.lsp_dynamic_workspace_symbols, opts)

With this config, when I open the source file, press <leader>fs and then type S, I don't see the S struct symbol in the listed results (unless I have a buffer with the header also open). On the other hand, if I do :Telescope lsp_workspace_symbols query=S, I do see the symbol in the results. I also see it with <leader>fS.

I tried without fzf as well.

I'm not familiar with the inner workings of nvim and its plugins. What steps can I take to help debug this?

Ok I'm able to replicate this now with/without a minimal config. But it's not consistent. Like ~50% of the time it still works.

Either restarting neovim or the lsp server with :LspRestart seems to change the outcome. But you're right, passing query=S does seem to work every time.

I'll have to investigate this more.

I tried to repeat the search and after 5 times or so I was skeptical but it ended up working the next try haha. So it appears indeed to be the case!

Here's an intuition (which might well be wrong, given that I don't know anything about Telescope implementation). Could it be that the interactive menu launches an async query when you type characters, but then not wait before displaying the results, i.e. a race condition?

I've been subscribed to this issue hoping for an update. Seeing as you just closed it as completed, could you please share how it was completed?

I believe this might be some language server limitation.

Under certain circumstances, I'm seeing vim.lsp.buf.workspace_symbols with a blank query (what telescope basically does), also requests in no results. Inspecting the LSP logs, I see the request going out, and getting a response with result = {}.

If I pass a query string, I get valid result with both telescope and built-in workspace_symbols().

I think I may be hitting this issue as well, though I am somewhat new to neovim so forgive me if this is something else entirely... Specifically, I am referring to the popular kickstart project's init.lua file. For example: https://github.com/nvim-lua/kickstart.nvim/blob/master/init.lua#L460.

Just incase this link is stale, they are setting up LSP goto definition like so: map('gd', require('telescope.builtin').lsp_definitions, '[G]oto [D]efinition'). So I am under the impression that Telescope's builtin lsp_definitions is attempted to be run. When I use this shortcut while hovering on something in normal mode..... Nothing happens.

For what it's worth, I'm using clangd as my project is written in C. Also, when I try to run the steps as mentioned in comment https://github.com/nvim-telescope/telescope.nvim/issues/964#issuecomment-1741967637 but using my project's source code, I see same behavior:

Interactive mode of :Telescope lsp_workspace_symbols does NOT yield results. Running :Telescope lsp_workspace_symbols query=<function_name> does yield results.

Perhaps a hint? When in interactive mode, I see a 100/100 on the side but when using query parameter, it shows 1/1. Perhaps there is an arbitrary limit of some sort for a list that's actually searched but when using query parameter no such limitation exists? I'm probably reaching...

I'm back to not being able to replicate this at all :sweat_smile:

@BlakeNoel can you try :lua vim.lsp.buf.workspace_symbols() and see if you get any results in a quickfix list in your use case?

I still feel like there's something fishy outside of telescope's implementation.

Alright so I'm hovering on a function name in a *.c file right now.

1. Interactive mode of :Telescope lsp_workspace_symbols does NOT yield result when typing this same function in.
2. Running :Telescope lsp_workspace_symbols query=<function_name> also does NOT yield result when typing this same function in. I get the same error seen in original bug: [telescope.builtin.lsp_workspace_symbols]: No results from workspace/symbol. Maybe try a different query: 'Telescope lsp_workspace_symbols query=example'
3. I am trying to run your recommended lua call, but I get the following error:

E5108: Error executing lua [string ":lua"]:1: attempt to call field 'workspace_symbols' (a nil value) stack traceback: [string ":lua"]:1: in main chunk

Sorry I meant :lua vim.lsp.buf.workspace_symbol() (singular symbol). It will prompt you for a query, similar to telescope, but you can just hit enter to see all symbols.

My guess/hope is that with/without the query, we should see the same results.

Thanks for the clarification. I tried that and hit enter as you say, and now I see "all the symbols" but the list is only 100 symbols long and does not include the function I am testing against. This 100 count seems mighty suspicious and is the same 100 as what telescope apparently is limited to (my theory) as I mentioned here: https://github.com/nvim-telescope/telescope.nvim/issues/964#issuecomment-1982069076.