Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
I just don't like this proposal because it "hacks" LSP support into each relevant use case instead of augmenting the existing TM infrastructure with LSP information. It adds individual band-aids for each use case and leaves behind other uses of the TM infrastructure (in other plugins). It's OK to get familiar with LSP and have something to showcase "geany-on-lsp" but it's not something that I comfortably support going forward.
Once again, this is how LSP works - if you want an autocomplete list, you ask the server to provide it for you using the completion request:
…
Similarly, if you want go to symbol definition/declaration, you use
…
When you want to get information for colorization of types or other symbols, you use
…
For calltips you call
…
For symbol tree, you callAnd so on.
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?
Seems horrid. Maybe if LSP severely limits the features we may implement it's not the right tool for us. Or we use LSP in a way that allows us to implement our features using the interfaces that are available, regardless of how someone else declares "that's how LSP works".
Put another way: Assume I want to implement a "class summary" tab in the sidebar, a HTML rendering of the current class (defined by cursor position), including all members (types, signatures) and their visibility.
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.
LSP servers ought to provide the symbols for files via DocumentSymbol or SymbolInformation. That should all be needed to build up a TMTags array attached to TMSourceFiles (without actually parsing via ctags) [1]. Sure, an LSP might not provide all the bits we want, but as @elextr said that may be the case with poor ctags parsers as well, or this very server instance is not worth asking anyway.
You can surely do that but the question is why would you do that. You get identical (or worse) info regarding individual symbols than from TM but enough for the symbol tree (which is the purpose of this particular LSP call). But you can't derive any extra info from it for the "smart" features like goto declaration/definition or autocompletion - you don't get info about types of the symbols, their visibility etc. - this is all hidden in the implementation of the LSP server.
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.
Further, you are not even guaranteed that the server implements the
textDocument/documentSymbolcall in which case you won't implement anything on top of that - yet the server may provide the goto declaration/definition call or autocompletion functionality.
I truly think that DocumentSymbol/SymbolInformation is the very basic interface that any worthwhile LSP server implements. How else do you get to learn about any symbol in a file? You need a symbol list to pick one for advanced stuff like goto-definition don't you? So if those aren't implemented the server is useless. Do you know an example of such a limited server?
You already implement complex features like symbol tree and call tips and more using LSP so the protocol itself must be sufficiently suitable for us, right?
Symbol tree isn't a complex feature in terms of symbol processing - you just display them (it's just all the annoyance with GtkTreeView). But if you want to implement a good autocompletion or symbol goto taking into account the symbol visibility, you just have to call the corresponding LSP call - without this you'd degrade the whole LSP to the not-so-good TM-style goto or autocompletion and the LSP doesn't make sense here.
Why do you think I want to take visibility into account for go-to? That would mean I cannot go to the definition of a private member function from a foreign class. Yes, that code may be illegal, but in the editor I still want to perform that jump to resolve the situation, e.g. by moving the function to the public section. Does the LSP interface even allow that or am I constrained to what LSP thinks how my implementation of goto-definition should work?
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.
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.
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?
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.
To be clear, I don't insist the implementation has to look exactly the way I propose here.
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.
Another thing is the symbol tree which is probably the only feature which works in a more or less same way in LSP as in TM and doesn't bring much benefit compared to TM. So this one could be completely dropped if the patch is considered too big.
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.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.