@kugel- as @techee said, but more bluntly, you do not seem to understand what the Language Server Protocol (LSP, not Language Server Process for removal of doubt) is designed for and are making yourself look stupid by arguing without that knowledge. Please stop being disruptive, if you have suggestions to improve the implementation please make them, but I feel your "change it all" is not helpful.

The LSP is designed for the server to hold a current version of the semantic annotated abstract syntax tree for the program, and accurately answer questions using that. There is no API (that I can see) that allows that to be exported, just a flat or hierarchical list of symbols suitable for the sidebar.

The approach of having Geany call a plugin for specific functionality, or fallback to its own, is in principle a good one. Just that Geany has never called a plugin before so its a new concept and has no design yet. Maybe we need to think about it more generally. But it allows for progressive development as individual items of functionality can be converted one at a time and features that the LSP does not support can also fallback to the existing implementation. And if it all goes pear shaped most of the code is in the plugin, not Geany, so it can be removed relatively easily or an alternate implementation plugged in. The alternative is to build LSP into Geany and be much more disruptive.

To answer your last questions:

How do you plan to handle other various goto-definition cases that don't come from a document context?

The LSP works on a project basis, in the case of clangd it uses compile_commands.json to specify build data in a build tool independent manner. I read your question to be what happens for files that are outside the project? Basically clangd does its best without reading the include files that are not open (since it does not know where to find them), but that is nowhere near as good as a file addressed by a compile_commands.json.

And for call tips (mouse over in sidebar symbols)?

The servers can return an accurate function type for the function. As @techee and I discussed elsewhere, it is not just a copy of the declaration text that ctags provides, since it contains inferred information as well, so its better, but different. This would be the correct information to show but it is not implemented yet.

I guess it has the advantage that the LSP can infer whatever foo is in foo->func() and then jump to the right definition, instead of presenting the user the various func() overloads to chose from.

Yes, this is what I mean by "accurate", no need to show a go to list, "please Mr user you choose", the correct one is available and can just be switched to directly.

But we must make sure that other goto-defintion use-cases (no document context) are also backed by LSP data and not by a completely different parser that perhaps only parses half of the document compared to the language server. Otherwise the LSP integration is going to be a source of user frustration and bug reports.

As I said clangd seems to do its best for files without compile_commands.json and it seems to also check the current directory just in case, so flat projects like Geany will "just work". But it depends on the server, and of course for "modern" languages other mechanisms may be used.

But ultimately neither we nor any other IDE (even Vscode) control what the server writers provide, thats why servers provide capability handshakes so features not supported can fallback to whatever the IDE chooses, in which case TM or nothing is the choice.

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