So to my understanding both sidebar features have to be implemented using the fallback.

I think you misunderstand the purpose of the goto-implementation, signature and documentSymbol calls:

I think understand the intention of the LSP interfaces. That's why I'm pretty clear that they cannot be used itself for implementing goto-definition and tooltip on the symbols sidebar. These functionalities in Geany have to be implemented using other LSP interfaces or the TM fallback.

I now looked at your changes in more detail and found that you accordingly don't use the goto-implementation and signature interfaces for the sidebar. My previous understanding of the PR was that these sidebar features are implemented using the TM fallback (doc->tm_file->tags_array) but that was a false understanding. Sorry for that!

But the fallback, as proposed in this PR, relies entirely on TM backed by ctags parsing.

No, this PR uses documentSymbol symbols for the sidebar (shows symbol name in the tree, shows "detail" as the calltip, generates tree based on children and assigns icon based on kind). I was just suggesting that if this PR is considered too big, I could sacrifice this LSP feature and could live with the TM implementation.

But this is essentially what I want that we do generally. I looked at your code in more detail and you're actually doing what I'm asking for all the time: you're generating TMTags from the LSP data. Now can we not go one step further and not only attach these tags to the sidebar menu items but to the GeanyDocument itself?

And please don't re-iterate the "documentSymbol" support is not guaranteed. To me this is basic functionality for any language server. If that's not provided the server is worthless (we couldn't have the symbols sidebar at all!). Please show me one server that does not provide it at all.

The quality of the implementation is a different matter but that's no different to our ctags parser. These also vary widely, not just in terms of parser results but also performance. We are never guaranteed good support for some languages. And this is something we accept and get along with. It's always "best effort". The same applies to whatever language server we talk to.

You said that just documentSymbol might give inferior results for doc->tm_file->tags_array, compared to our ctags parsers. Is that always true or does it depend on the server? What about C/C++ and the clangd server for example? I want to get a feeling if the documentSymbol interface itself is lacking or if existing servers aren't good enough.

Speaking about superior ctags parsing: I understand your implementation is susceptible for this scenario for the sidebar use cases: If the language server does not provide detail in documentSymbol, then we won't have a tooltip. Similarly, if the server does not provide range/location then we won't have goto-definition. Now if we would have that information in the TM fallback because the parser recorded this information in doc->tm_file->tags_array, then these two use cases are effectively regressed. I don't have a feeling how realistic this is because I don't have a good picture about the quality of server implementations, but generelly speaking this is a situation that I want to avoid if possible as it would make our LSP support look poor compared to the status quo, even if it excels in other use cases.

On the other hand, if we follow-up on your other idea and use LSP even to interface with the ctags parsers then documentSymbol ought to be sufficient for all existing features (except maybe where we can specialized LSP interfaces like goto-implementation), right?

I can believe that you or @techee don't care about goto-implementation and calltips enough on the sidebar but I do.

But this works, I really don't know what you are talking about. Have you actually tried the bloody plugin? It's a few minutes of your time to install and test it - would really save hours of pointless discussions.

I never questioned that your plugin works, at least for C/C++ where we have a solid TM-based fallback as well. I could find the above only by code study not just by testing.

Actually testing requires me to setup an LSP server (or perhaps multiple ones) which I don't yet know how to do so I'm afraid it takes more than a few minutes of my time.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.