Idea - use nvim's "go to definition" command to support all file types about goto-preview HOT 7 CLOSED

Hi!
I'm not an expert too, but I recommend to take a look at the lspsaga source, I think they solved this issue.

https://github.com/glepnir/lspsaga.nvim/blob/cb0e35d2e594ff7a9c408d2e382945d56336c040/lua/lspsaga/provider.lua#L449

https://github.com/glepnir/lspsaga.nvim/blob/cb0e35d2e594ff7a9c408d2e382945d56336c040/lua/lspsaga/provider.lua#L472

from goto-preview.

@Gelio the flow you are suggesting is something along the lines of

1. Open window -> execute jump to definition -> open window -> execute jump to definition
   Whereas I'm suggesting
2. Get definition data -> open window to correct location -> get definition data -> open window to correct.

Btw I'm not suggesting that that wouldn't work but rather that depending directly on this functionality is less flexible i.e. rather than having this work exactly the way this plugin needs it depends on the specific behaviour of that api meanwhile the only thing that is actually needed from that function is how it converts the lsp location data into a vim address for all filetypes.

Say the plugin wanted to be able to do something with the locations it had opened so far can't think of what but it wouldn't have any internal knowledge of what the path was without maybe having to dig around the jump list or something.

It would also require a refactor towards this less flexible method rather than copy pasting what I'm guessing are a few lines into the location handling 🤷🏾 any just my 2 cents will leave this for the author 👍🏾

from goto-preview.

Hey all, cool discussion here!

Apparently, there aren't as many variations as I initially thought?
I'm changing this to do something like @hobord's suggestion with what lspsaga does. Thanks for pointing me to that chunk of code!

from goto-preview.

I think @hobord's makes a good suggestion. I think you should be able to generalise, the functionality to all filetypes since nvim is able to jump to definition for all lsp filetypes. I think as the lspsaga example shows it's probably a matter of checking a few different formats. I think you could probably re-use the logic inside vim.lsp.buf.goto_definition rather than depending on it directly.

from goto-preview.

Thanks for providing additional suggestions. I'm wondering what's the benefit of using some additional logic rather than using a built-in nvim API for going to the definition. I would say calling a single function should be easier but looks like I may be wrong. Do you know?

from goto-preview.

@Gelio the lsp handlers are quite specific about how they work and their internal workings can't be easily overriden i.e. go to definition not using the current window but a float instead.
This is why lspsaga as an example re-implements a lot of the handlers or uses some of the other lower level utils rather than tries to re-use the methods directly.

I think rather than trying to work around this behaviour which frankly could change (granted that's unlikely as the API stabilises) it's better to just use the functionality/utils the lsp exposes to produce the exact desired outcome. This is all up to @rmagatti anyway though so 🤷🏾 , just my opinion

from goto-preview.

@akinsho Thanks for answering. I still don't understand one thing, though:

the lsp handlers are quite specific about how they work and their internal workings can't be easily overriden i.e. go to definition not using the current window but a float instead.

In the steps I have listed in the issue description, using the current window is exactly the behavior we want, is it not? So, it would appear to me that if only the plugin opened a floating window with exactly the same buffer as the main window and then invoked vim.lsp.buf.definition(), that floating window would now show the definition, exactly as it does right now, but without having to configure each filetype.

I don't see the need to use lower-level utils here. What am I missing?

from goto-preview.