Open solson opened 1 year ago
I've done some investigation and I believe I know the cause of the issue as well. Note that in every case, the file being loaded has a "virtual" name like deno:/asset/lib.deno.shared_globals.d.ts
or slightly different for dependencies.
Following the definition of vim.lsp.buf.definition()
:
function M.definition(options)
local params = util.make_position_params()
request_with_options('textDocument/definition', params, options)
end
local function request_with_options(name, params, options)
local req_handler
if options then
req_handler = function(err, result, ctx, config)
local client = vim.lsp.get_client_by_id(ctx.client_id)
local handler = client.handlers[name] or vim.lsp.handlers[name]
handler(err, result, ctx, vim.tbl_extend('force', config or {}, options))
end
end
request(name, params, req_handler)
end
I noticed that it calls client.handlers[name]
and sure enough, lspconfig's denols
settings defines relevant handlers:
Then this calls into here:
Notably, this checks for the deno:
prefix like in our original example of deno:/asset/lib.deno.shared_globals.d.ts
, and it handles it using an LSP request to deno/virtualTextDocument
.
I don't think telescope's lsp_definitions
can work like vim.lsp.buf.definition
in general unless it routes through these server-specific handlers.
(Worth noting that this can also affect lsp_type_definitions
and the others, as well as not being Deno-specific, if any other LSP uses handlers like this, but this is the case I ran into and knew how to make a minimal repro for.)
It is probably interesting to note that trouble.nvim appears to have the same kind of bug (not invoking client-specific LSP handlers, and thus failing to handle Deno in the same way), so I opened a discussion.
Thanks for the report and investigative findings. Really helps a lot.
I think I can put together a fix for this. Tricky this is that client handlers can do arbitrary things and it looks like the denols handler in lspconfig calls the base neovim lsp handlers, which already handles the jumping to definition or opening a quickfix list. Obviously we want telescope to open instead of a quickfix list.
Luckily there's a on_list
config option we can pass to the these handlers whereby we can pass function to collect the lsp response. I think telescope can leverage this so I'll try this.
I created a PR https://github.com/nvim-telescope/telescope.nvim/pull/2770
In my limited testing, this seems to fix these kinds of issues for the definition
, references
, typeDefinition
and implementation
pickers.
I think the rest of the lsp based pickers will also need a similar treatment but if you can give this PR a try it'll be great.
I'd like to get @Conni2461 to take a look as well.
This is still broken.
I don't know if it is of any help, but after running vim.lsp.buf.references
once, the telescope built-in alternative works without preview. This might happen with definitions
too.
Screen recording:
Hi, I have the same issue for angular project, vim.lsp.buf.definition()
, Trouble
and FzfLua
are working, but telescope says [telescope.builtin.lsp_definitions]: No definitions found
.
Is there some way to implement fallback to go to native vim.lsp.buf.definition()
if no definitions is found by telescope?
Hi, I have the same issue for angular project,
vim.lsp.buf.definition()
,Trouble
andFzfLua
are working, but telescope says[telescope.builtin.lsp_definitions]: No definitions found
.Is there some way to implement fallback to go to native
vim.lsp.buf.definition()
if no definitions is found by telescope?
@yavorski check that this isn't a file_ignore_patterns
issue involving node_modules.
Telescope shouldn't be unique to this issue. See below.
Trying to take another look at this.
In my testing, trouble.nvim
and fzf-lua
handle lsp_definition
for the "steps to reproduce" above all yield the same error.
Trouble
FzfLua
Telescope
The trouble is, these LSPs with custom handlers can theoretically do anything and I don't think there's a reliable way for plugin authors to account for the results of these handlers.
https://github.com/nvim-telescope/telescope.nvim/pull/2770 should work for most cases where the custom handler ultimately calls the appropriate vim.lsp.handlers.*
.
The other option is allowing users to write custom handlers specifically for telescope but I don't realistically see 99% of people managing that. And telescope is certainly not in a place to maintain telescope specific nvim-lspconfig type handlers.
I think the best approach would be to flip the current telescope lsp implementations around a bit.
Many of the vim.lsp.buf.*
functions (eg. definition
/references
) take a on_list
option that takes a function to handle the list of items returned from the language servers + handled by client handlers.
Going with this approach would significantly simplify telescope's current lsp related pickers as well.
Only problem is, I believe on_list
is a neovim 0.10 feature and we're still stuck supporting 0.9.5 even on nightly telescope.
I've implemented this https://github.com/nvim-telescope/telescope.nvim/pull/3335
But unfortunately, looks like neovim's lsp functions currently on nightly don't use client/global handlers either https://github.com/neovim/neovim/issues/30908#issuecomment-2432578080
type MapNever<T, U> = { [K in Exclude<keyof T, keyof U>]?: never }
type XOR<T, U> = (MapNever<T, U> & U) | (MapNever<U, T> & T)
export {}
require("telescope.builtin").lsp_definitions()
fails in typescript with inner type Exclude
got msg:
[telescope.builtin.lsp_definitions]: No LSP Definitions found
but vim.lsp.buf.definition()
works
https://github.com/user-attachments/assets/ae0ea4e6-40a8-459e-b6f8-2f218eafe727
nvim --version
NVIM v0.10.2
Build type: Release
LuaJIT 2.1.1713484068
Run "nvim -V1 -v" for more info
telescope.nvim
url https://github.com/nvim-telescope/telescope.nvim
branch master
commit 85922dd
Description
Using
require("telescope.builtin").lsp_definitions()
fails even whenvim.lsp.buf.definition()
works in the Deno LSP for a dependency or builtin (likeconsole.log
). See recordings in expected/actual sections.Neovim version
Operating system and version
nixos-unstable (Linux 6.1.60)
Telescope version / branch / rev
telescope 4522d7e3ea75ffddabdc39957168a8a7060b5df0
checkhealth telescope
Steps to reproduce
minimal.lua
and the following.touch deno.json
(so the LSP sees this as a project root).echo 'console.log("hello world")' > foo.ts
nvim -nu minimal.lua
:e foo.ts
:Telescope lsp_definitions
(onconsole
orlog
).Alternately, to see the successful outcome, replace step 7 with
:lua vim.lsp.buf.definition()
, but not during the same execution becausevim.lsp.buf.definition
andlsp_definitions
change each other's outcomes if run in succession in the same Neovim session.Expected behavior
When I use
vim.lsp.buf.definition()
for a dependency or builtin (likeconsole.log
), it works correctly: asciinemaActual behavior
But when I use
require("telescope.builtin").lsp_definitions()
, it fails: asciinemaMinimal config