behaving even more like vanilla tagfunc?

[andymass]

Hey!

First of all, this is a great plugin. I love the concept of a small plugin which integrates neovim's lsp with tagfunc and just gets it right. I wonder though, can we go even further? In particular;

Using this plugin will remove the ability to search for arbitrary tags with any of the tag related ex-commands. As long as a language client is available, the current cursor location is used by the server to determine the results.

How about if the user types :tag foo, using workspace/symbol to search along the word foo? This seems roughly similar, but smarter than using a tagfile.

The other use-case I have in mind is when the user types just :tag. In vanilla vim, this is supposed to jump to a newer entry in the tagstack. I tried this out a bit with the plugin and I'm not sure what is happening right now. It's a bit tricky because we need to store enough information to actually recall the tag. This is one reason I added "user_data," for bookkeeping.

I am almost certain it's possible to get LSP sourced tags near vanilla-like. I tried hard to take care of this when I modernized and got the tagfunc patch merged into vim.

[weilbith]

How about if the user types :tag foo, using workspace/symbol to search along the word foo? This seems roughly similar, but smarter than using a tagfile.

I don't think this straight approach is the right idea. This would basically remove all the smartness of the language server. Just imagine a variable with a typical name or which you just declare several times in the same file. Or an overload implementation, ... This would mean that document/symbol would have multiple entries for this "word". Which should we take? For tags commands you would either stupidly jump to the first one or get a list of all candidates. But you actually want a smart jump by a tool who knows the code.
For workspace/symbol this is even worse. Also I made the experience that many language servers do not support this provider well (e.g. tsserver).
Furthermore does the plugin summarize the different locations according to declaration, definition, implementation etc. How would you like to integrate this feature in this plain search?

Maybe I got your approach wrongly. I was thinking for a long time about your words to interpret them. And I read again through the help of the tags command to see if we could make both approaches work in parallel. But I don't see it. Please elaborate again if I got you wrong.

The other use-case I have in mind is when the user types just :tag. In vanilla vim, this is supposed to jump to a newer entry in the tagstack. I tried this out a bit with the plugin and I'm not sure what is happening right now. It's a bit tricky because we need to store enough information to actually recall the tag. This is one reason I added "user_data," for bookkeeping.

Where did you added the user data? Do you wanna open a PR to fix this single part?

---

Thanks for your intensive interest into this plugin.
As a site note I must admit that I don't use this plugin myself atm. I'm waiting for my issues to modernize the location picker and previewer functionality. I actually planned to do a NeoVim PR myself which allows to set a previewfunc and something similar for the tag list selection. But atm nobody is interested into it and want to help with the C code of it.
So for daily professional work I prefer tools which visually provide a faster and better flow. I just got annoyed of the bad usability experience. But as soon as the other parts are fixed/extended (and if I have to do it myself), I go back to this plugin here. Its just a matter of being able to work efficient atm.

[andymass]

Thanks for your input!

As a site note I must admit that I don't use this plugin myself atm.

Totally understand if this plugin doesn't fit your current workflow and vision. I can always leverage your work as a great starting point.

For workspace/symbol this is even worse. Also I made the experience that many language servers do not support this provider well (e.g. tsserver).

This is a really good point which I trivialized. You're right- the plugin would probably need to apply some smart ordering logic on top of the LSP and it's not clear if this is even possible based on the information given in the LSP response. I was also not aware it isn't well supported by some language servers. I'll have think on this some more.

Furthermore does the plugin summarize the different locations according to declaration, definition, implementation etc. How would you like to integrate this feature in this plain search?

I think this must be a fifth "kind," of workspace Symbol. The logic here is if the user types ":tag foo" they really mean get me everything named foo without reference to a starting location or type (decl, defn, etc). Normally in vim, typing :ts foo brings up a selector where you can choose the one you mean.

Where did you added the user data? Do you wanna open a PR to fix this single part?

Sure, I'll hack on this a bit and open one.

allows to set a previewfunc and something similar for the tag list selection

Interesting, what would previewfunc do exactly? Do you mean this feature would replace vim's old :ts with a modern interface of the user's choosing?

[weilbith]

Interesting, what would previewfunc do exactly? Do you mean this feature would replace vim's old :ts with a modern interface of the user's choosing?

(Neo-)Vim has this feature of a preview window. It is a specific window, with a special option and there is only one of it at the time. It is for example used for :ptag to preview a tags location. But I assume you all know that. Just wanted to make sure we talk about the same.
My imagination is to have an option like previewfunc which follows tagfunc, foldexpr, indentexpr, formatexpr, completefunc, omnifunc etc. It would allow to set a function which handles the window creation/detection and return the window/buffer id. Or take it further and provide it with a location to preview. But that might be too limited as it must not be a location that gets previewed. After all there could be various minimal plugins that provide such a function for floating windows, external UIs, ...
Anyway I have no experience with the C code-base and nobody else seems to be interested.
I just would like to get control of all the emerging plugins, where each of them manages their own preview windows instead of continuing what Vim is good at and provide a strong base interface. The concept of locations, etc is nothing new and was called tags. With language server we got way more precise and easier to maintain "tags". But they differ a little. But instead of throwing away everything we had for tags, I would like to adopt and make both work similar. The tag functionality was well defined in Vim. LSP location providers are not and everyone implements a different usage on top of it.

PS: Sorry for the long and rude text. 🙈

[andymass]

Ah, got it now. Thanks for explaining. I'll just mention in the chance you haven't seen it, that there is a setting previewpopup which makes :ptag and :pedit open in a popup window. I haven't used it much myself so I can't say whether it works well or not.

For tags only, another potential option you have is to use a ex command callback like call module#do_work(3, 4)|;" which in theory may be able to do anything, like open a popup window, though I also haven't tried that.

With respect to modifying neovim C code base, you may find it easier to add lua callbacks or hooks rather than adding a new option, which is scrutinized lately. I am aware of nvim's LSP "handlers" but this seems rather different than what you're proposing.

If you are so inclined, feel free to link to any prior mentions about your ideas and requirements on github/gitter. PS unfortunately I most likely won't have much free time to do any substantial development, but I'm interested in tracking developments.