Open solson opened 9 months 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:
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