I don't know what exactly you want to see in this class summary, it sounds like you could obtain the necessary information

We don't have to deep dive into that. I just made up an example that doesn't have a specialized LSP interface. Your reply was expected: Use other interfaces (maybe multiple ones) that provide the necessary information. This is alright. I just want to get past the "use only LSP interfaces for their original intention" argument because it would stop you from implementing new features until a specialized LSP interface arrives.

But why would I mix different LSP interfaces when there are specific interfaces for the purposes we need? That's nuts.

Because, for example the goto-definition LSP interfaces does not work in all situations (needs a source code location as input, see below). When it's applicable then it should be preferred, that's for sure.

And nobody says we should drop the TM symbols

I think we're clear on that, nobody suggests that. We're disagreeing whether LSP data should augment the TM-ctags-based fallback. I maintain it should be done so that use cases that require the fallback don't regress or remain unavailable entirely.

I think it would make a lot of sense to make a LSP server from the tag manager and access it only through the LSP interface.

I think that's a fine idea and it goes much in my direction because it ensures that we can realize all existing functionality over LSP (unless you want to drop some functionality in the process?). Lets discuss that idea elsewhere, though, this PR is already becoming confusing.

@elextr

@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.

Sorry if I sound stupid but I don't really care what LSP was originally designed for. I care if we can make LSP and Geany fit together. Perhaps that may require using LSP interfaces for other purposes than their original intention. I don't want to turn Geany up-side-down just to make it fit the LSP design (at least not all at once). This is why I want to keep TM infrastructure working and consistent when LSP is in effect.

I'm not even too attached to the ctags parsing itself. But lots of functionality requires TM even with this PR and I don't want to lose it if LSP is in effect, and ideally I want to have this functionality for languages where LSP is the only option (where we have no parser).

The way I use Geany depends on TM but I too want to benefit from LSP. Is that hard to understand?

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.

To my understanding, LSP just exposes interfaces that give information about the documents or projects. Whether the server keeps an AST is an implementation detail and the server may have other means to provide the interfaces.

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.

I don't disagree. But entire point is that the "fallback to its own" is consistent with LSP data. I don't want use cases that cannot be mapped to LSP interfaces to regress when LSP is in effect. Because I think 1) LSP support is not going to be successful if it creates regressions on other areas and 2) it creates support nightmares because users may run on inconsistent data backends. The "if you use an LSP plugin you're on your own" excuse does not work always if we support a plugin API specifically for that and the issues get created anyway.

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.

No, I don't mean "outside files". I mean UI interactions that are not tied to a document or an exact source code location. Both Goto Implementation and Signature Help interfaces have the current cursor position as input. I can't directly request the location or signature of function foo(), I do need to write the call to a source file so that the language server can read the code and infer context from that source code location.

Example:
The sidebar symbols both offer goto-implementation (click on a function) and calltips (mouse-over tooltip). But in the sidebar you don't have a cursor position. I do not see how you can possibly implement the two functionalities using the LSP interfaces designed for that purposes, but using the intended interfaces - and only those - is @techee entire argument.

So to my understanding both sidebar features have to be implemented using the fallback. But the fallback, as proposed in this PR, relies entirely on TM backed by ctags parsing. Now we can have the weird situation that the sidebar lists symbols that the fallback does not know about, thus goto-implementation and calltips on the sidebar might not be available. The other way around is also plausible (although unlikely): the ctags parser may have parsed more symbols (or more modifiers) than the LSP server and the sidebar wouldn't list them even if Geany knows about them.

And this is the exact situation that I do not want to happen. I think we can achieve that if we try a little better by also mixing LSP data into the TM fallback, as a best effort solution to keep the TM fallback and primary LSP data source consistent.

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

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.

Hopefully it won't do nothing if I accidentally call a private function that is not available from the call site in question. I still want to jump to the implementation in that case.

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