Problems with LSP shared by Telescope and Trouble

[solson]

I don't (yet) use Trouble actively, and don't have time to fill out a proper complete bug report, but I think some people might be interested that Trouble seems to have an equivalent version of this bug I filed in Telescope.

The similarity in both cases is that, unlike vim.lsp.buf.definition(), both :Telescope lsp_definitions and :Trouble lsp_definitions do not invoke LSP client-specific handlers, and thus fail when encountering features like Deno LSP's special deno: URLs which are used for jumping to builtins or remote dependencies.

Specifically, nvim-lspconfig's denols support sets up the handlers to make vim.lsp.buf.definition() work properly.

In Trouble's case, when using :Trouble lsp_definitions on a builtin like console.log, the error is a bit more to the point:

Error executing vim.schedule lua callback: ....local/share/nvim/lazy/trouble.nvim/lua/trouble/util.lua:158: ENOENT: no such file or directory: deno:/asset/lib.deno.console.d.ts

stack traceback:
        [C]: in function 'assert'
        ....local/share/nvim/lazy/trouble.nvim/lua/trouble/util.lua:158: in function 'process_item'
        ....local/share/nvim/lazy/trouble.nvim/lua/trouble/util.lua:208: in function 'locations_to_items'
        ...are/nvim/lazy/trouble.nvim/lua/trouble/providers/lsp.lua:67: in function 'handler'
        ...are/nvim/lazy/trouble.nvim/lua/trouble/providers/lsp.lua:9: in function 'handler'
        ...eovim-unwrapped-0.9.4/share/nvim/runtime/lua/vim/lsp.lua:1393: in function ''
        vim/_editor.lua: in function 

I'm not yet familiar enough with Neovim LSP support and nvim-lspconfig to know what a universal solution should look like, but it would be excellent if there was some shared mechanism to ensure vim.lsp.buf.definition(), Telescope, and Trouble all act the same way here.