Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
I'm not sure if I want to continue in this but one more round...
So you're suggesting that any one editor or IDE may only implement features for that a specialized interface in the LSP exists, and no more? I.e. features that are blessed by the the LSP (=VSCode) folks?
Anyone can implement anything of course but LSP servers are specialized in doing certain things (and in the case of clangd, for instance, significantly better than what we could possibly ever produce), why not use them? And of course we fall back to our TM otherwise.
I don't see a special ClassSummary interface in the LSP spec. Does that mean I cannot implement this feature? What are the options, assuming we didn't have TM anymore.
I don't know what exactly you want to see in this class summary, it sounds like you could obtain the necessary information
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_prepareTypeHierarchy
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_documentSymbol
But just displaying symbols is easy, you don't need anything special for that and something like our TM is mostly enough for it. What's hard is good autocompletion, symbol goto, or calltips showing only relevant info.
Depending on the language this might give more or more accurate (w.r.t. to build configuration). Probably you can also mix different LSP interfaces to get a more accurate picture about individual symbols.
But why would I mix different LSP interfaces when there are specific interfaces for the purposes we need? That's nuts.
My point is: It may be nice that LSP provides specialized interface for some features. But it doesn't do for all imaginable features, and the existing interface might also not fit perfectly to our requirements. So we have to think about fallback solutions by mixing multiple existing LSP interfaces.
I don't know what "all imaginable features" you have in mind. We definitely won't implement "all imaginable features". We want good autocompletion, we want good symbol goto, we want good calltips. All these are provided by the LSP interface. And if you want something special (and please tell me what exactly you want), sure, you can implement it using a combination of calls (but I don't know how you combine autocompletion with symbol goto together with calltips into one thing and what you expect from it).
NB: I did not find in the LSP spec that goto-definition takes the visibility into account. What does goto-definition add over DocumentSymbol anyway? The latter includes the symbol location and goto-definition doesn't return anything else.
That's not documented (it's irrelevant to the interface itself), it's just how e.g. clangd works - it goes to the right spot e.g. based on what you included in the given file. The difference between documentSymbols is that documentSymbols returns all symbols of the current file while definition gives you the location where to jump across the whole project with all the bells and whistles like taking into account class hierarchies, includes, etc.
Actually, the LSP interface for goto-definition seems take to be a position in the text file (probably a call site) as input. That implies that this interface is not suitable when you don't come from a document context. For example, one of my plugins offers a dialog where you can enter a function name, in order to look it up and then go to it's definition. Seems the goto-definition LSP interface cannot be used for that purpose, meaning I have to look-up DocumentSymbol. Also you can click on a symbol in the sidebar to jump to its definition. How do you handle that?
You could use workspaceSymbols if you want to do it for the whole project
or documentSymbols
and filter-out the symbols you are interested in. But this is simple, it doesn't any advanced logic like goto based on the current location.
At least for things like these we're back to square one: We do need an offline database for symbols even for things like goto-definition.
And nobody says we should drop the TM symbols, I'm just saying that if you imagine you get some better symbol information from LSP calls like the two above than what we get from TM, you are mistaken. There may always be files that get mis-parsed by the relatively simple TM parser so regarding parsing LSP will probably have the edge over TM but the information inside the symbols themselves will probably be inferior to what we have inside our TMTag structure.
As I mentioned here #3571 (comment), you can't rely on the exact contents of the detail field unless you want to hard-code some rules specific to various LSP servers (and I'm very against it) so without it you lose the type and the signature of variables/functions. I also think that many servers return just a flat list without hierarchicalDocumentSymbolSupport so you lose scope. What remains is symbol name, kind (which doesn't exactly correspond to our TMTagType and we can't even be sure which ones the server supports), line number and that's pretty much it.
I care mainly that the TM infrastructure is still intact. And not because we still parse the file with ctags but in a way that ensures consistency with LSP data.
Assuming we fill TM using LSP data, then this consistency is given. We can then decide if we use that or use a specialized LSP interface to implement feature X or Y. But we do have to ensure that we have a solid and consistent TM infrastructure at all times.
You are not guaranteed to have that even in this case. When you consider pylsp:
https://github.com/python-lsp/python-lsp-server
it uses various external tools for various features and I doubt it will always behave in a consistent way.
That's worst. Then symbol tree and everything else is based on ctags-parsed data and actual user-interaction features are based on external LSP data. Unless both ctags parser and language server are high quality and give comparaible results this will just give the user confusing (because inconsistent) results if both worlds don't match well (e.g. if the ctags parser is too simple/limited). E.g. you may get a fine call tip for symbols that aren't visible in the sidebar or elsewhere.
Well, I would always prefer a good calltip over a bad calltip that is consistent with the list of symbols. And as I said above, if you want to fill the TMTag structures from LSP, you can't completely rely on what's in detail so you probably won't fill-in signature in TMTag and will lose it in the symbol tree anyway.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.