Closed linglingqi007 closed 8 months ago
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_workspacesymbol query=marshal and lsp dynamic_workspace_symbol, and then search for marshal, and get many results that are not in the current workspace.
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.
header.h
:
struct S
{
int m;
};
#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:
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.
:Telescope lsp_workspace_symbols
does NOT yield result when typing this same function in.: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'
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.
https://github.com/nvim-telescope/telescope.nvim/issues/964#issuecomment-1200157618 lsp_dynamic_workspace_symbols execution error when there are multiple LSP clients
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 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
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_symbolsEnvironment
- 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: 1dd6f84Configuration
No telescope configuration