nvim-telescope / telescope.nvim

Find, Filter, Preview, Pick. All lua, all the time.
MIT License
15.66k stars 828 forks source link

Telescope lsp_workspace_symbol no result #964

Closed linglingqi007 closed 8 months ago

linglingqi007 commented 3 years ago

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

jameswalmsley commented 3 years ago

Try Telescope lsp_dynamic_workspace_symbol

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

linglingqi007 commented 3 years ago

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?

jameswalmsley commented 3 years ago

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?

linglingqi007 commented 3 years ago

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_workspacesymbol 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.

Conni2461 commented 2 years ago

Is this still happening?

sashomasho commented 2 years ago

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.

eyalk11 commented 2 years ago

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.

domas-v commented 2 years ago

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

image

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

image

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?

wqk151 commented 2 years ago

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

gmli commented 2 years ago

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.

uloco commented 1 year ago

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

uloco commented 1 year ago

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.

uloco commented 1 year ago

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!

mkaito commented 1 year ago

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?

oyarsa commented 1 year ago

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.

rjurga commented 1 year ago

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.**
jamestrew commented 1 year ago

@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.

rjurga commented 1 year ago

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

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?

jamestrew commented 1 year ago

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.

rjurga commented 1 year ago

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?

mkaito commented 8 months ago

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?

jamestrew commented 7 months ago

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().

BlakeNoel commented 7 months ago

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...

jamestrew commented 7 months ago

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.

BlakeNoel commented 7 months ago

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

jamestrew commented 7 months ago

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.

BlakeNoel commented 7 months ago

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.

JavaHello commented 3 months ago

https://github.com/nvim-telescope/telescope.nvim/issues/964#issuecomment-1200157618 lsp_dynamic_workspace_symbols execution error when there are multiple LSP clients

JonnySB commented 2 months ago

I'm also having this issue with pyright language server. Dynamic symbols work okay but as other's have mentioned, it's slow

jamestrew commented 1 month ago

I'm also having this issue with pyright language server. Dynamic symbols work okay but as other's have mentioned, it's slow

I'm coming around to the idea of deprecating (or at least aliasing) lsp_workspace_symbols in favor or lsp_dynamic_workspace_symbols.

There's no guarantee's about what the language server should return. And like you mentioned, it seems like it's within the purview of language server to not return any results without a query.

Yes there may be performance issues, but in my testing (setting lsp logging to DEBUG and watching requests/responses), it's a language server issue. Some are better than other and this might come down to workspace folder config as well. There's not much we can do on the telescope side.

Another thing regarding lsp_dynamic_workspace_symbols, currently Telescope does not sort results and lets the language server serve up the result ordering. Again, looks like language servers make no guarantees again what order they return things, so often times, it's bad. I'll try to address this first. https://github.com/nvim-telescope/telescope.nvim/issues/2104