[BUG] Does not play well with omnisharp-extended-lsp
Opened this issue · 10 comments
This is probably not a bug, but probably not a feature request either.
Besides omnisharp-nvim and lsp, I am relying on https://github.com/Hoffs/omnisharp-extended-lsp.nvim in order to find definitions for external libraries. In short, this enables me to open a scratch buffer with a generated definition of the external source file.
However, it does not work out-of-the-box with goto-preview, as I get the error:
Error executing vim.schedule lua callback: .../pack/packer/start/goto-preview/lua/goto-preview/lib.lua:158: Cursor position outside buffer
I am not sure if this is fixable or not. Might be that this is not a general enough case, might also be that something needs to be done in omnishharp-extended-lsp.
Thanks in advance for any amount of time you choose to spend on this.
Hi, @MikaelElkiaer would you mind showing me a full debug = true :messages dump of when you see this particular issue?
Also, I'd like to better understand what exactly isn't working out of the box. Are you trying to preview a definition from inside that scratch buffer for example?
@rmagatti Sorry for getting back so late, on an unclear issue description even.
I am trying to preview a definition which is not in my source code. The way I do that today, is by the plugin that I referred to, which uses the language server to grab the external library's metadata and put that into a scratch buffer.
And here you go, debug messages:
goto-preview: lib: {
border = { "↖", "─", "┐", "│", "┘", "─", "└", "│" },
bufhidden = "wipe",
debug = true,
default_mappings = false,
dismiss_on_move = false,
focus_on_open = true,
force_close = true,
height = 15,
lsp_configs = {
get_config = <function 1>
},
references = {
telescope = {
border = true,
borderchars = {
preview = { "─", "│", "─", "│", "╭", "╮", "╯", "╰" },
prompt = { "─", "│", " ", "│", "╭", "╮", "│", "│" },
results = { "─", "│", "─", "│", "├", "┤", "╯", "╰" }
},
hide_preview = false,
layout_config = {
height = <function 2>,
preview_cutoff = 1,
width = <function 3>
},
layout_strategy = "center",
results_title = false,
sorting_strategy = "ascending",
theme = "dropdown"
}
},
resizing_mappings = false,
width = 120
}
goto-preview: calling new handler
goto-preview: data from the lsp {
range = {
end = {
character = 35,
line = 11
},
start = {
character = 27,
line = 11
}
},
uri = "file:///%24metadata%24/Project/Beehive/Assembly/System/Runtime/Symbol/System/TimeSpan.cs"
}
goto-preview: focus_on_open true
[lspconfig] Autostart for omnisharp failed: matching root directory not detected.
goto-preview: {
bufpos = { 6, 26 },
curr_window = 1008,
get_config = {
anchor = "NW",
border = { "↖", "─", "┐", "│", "┘", "─", "└", "│" },
bufpos = { 6, 26 },
col = {
[false] = 0,
[true] = 3
},
external = false,
focusable = true,
height = 15,
relative = "win",
row = {
[false] = 1,
[true] = 3
},
width = 120,
win = 1000,
zindex = 1
},
get_current_line = "",
new_window = 1008,
windows = { 1008 }
}
goto-preview: dismiss_on_move false
Error executing vim.schedule lua callback: .../pack/packer/start/goto-preview/lua/goto-preview/lib.lua:158: Cursor position outside buffer
stack traceback:
[C]: in function 'nvim_win_set_cursor'
.../pack/packer/start/goto-preview/lua/goto-preview/lib.lua:158: in function 'open_floating_win'
.../pack/packer/start/goto-preview/lua/goto-preview/lib.lua:228: in function 'handle'
.../pack/packer/start/goto-preview/lua/goto-preview/lib.lua:259: in function 'handler'
/usr/share/nvim/runtime/lua/vim/lsp.lua:957: in function 'cb'
vim.lua:285: in function <vim.lua:285>
As you can see, the url is file:///%24metadata%24/Project/Beehive/Assembly/System/Runtime/Symbol/System/TimeSpan.cs which is not a find that can be found locally, but only requested via the language server. I guess this is why it fails.
Yeah you'd be right on that. If it can't be found locally it's kind of hard to make this work, since the way goto-preview works is by grabbing that data from the lsp and parsing it so it can open a preview on the right spot.
goto-preview: data from the lsp {
range = {
end = {
character = 35,
line = 11
},
start = {
character = 27,
line = 11
}
},
uri = "file:///%24metadata%24/Project/Beehive/Assembly/System/Runtime/Symbol/System/TimeSpan.cs"
}
Do you have any pointers for how I could extend your implementation in order to support this?
So from briefly looking at this code, from what I understand it does its own textDocument/definition call with its own custom handler.
https://github.com/Hoffs/omnisharp-extended-lsp.nvim/blob/main/lua/omnisharp_extended.lua
One thing that stands out to me is that your end uri contains %24metadata%24, when from reading the omnisharp-extended-lsp it looks like it should be unincoded, like such $metadata$. Can you locally find file:///$metadata$/Project/Beehive/Assembly/System/Runtime/Symbol/System/TimeSpan.cs in your system?
This might be as simple as a parsing issue after all.
I cannot find that file.
I am fairly certain that the file never exists, and the uri is used to query the LSP client (i. e. omnisharp):
https://github.com/Hoffs/omnisharp-extended-lsp.nvim/blob/9c76674be87e92b0090417359b063fe130d9c158/lua/omnisharp_extended.lua#L182
Which is eventually used in a scratch buffer:
https://github.com/Hoffs/omnisharp-extended-lsp.nvim/blob/9c76674be87e92b0090417359b063fe130d9c158/lua/omnisharp_extended.lua#L39
I see, so it probably just gets the contents from the LSP client and fills the buffer with it instead of it ever being an actual saved file somewhere.
One way I can think of to support this, or rather to open up more possibilities for any client would be to add an option to configure what to do after the lsp call, i.e when it gets the data from the lsp. One would grab that data and run their own function on top of it instead of goto-preview's regular function that would then call the necessary module functions, in this case to omnisharp-extended-lsp, and with the contents of the call create a buffer and then pass that into goto-preview's open_preview_window, which would have to be tweaked to support this too of course.
With that approach anyone could customize things to their need instead of goto-preview having to support how multiple different clients potentially work.
Sounds awesome, and I'd love to do it. Still new to neovim and lua, so it's gonna be slow going.