@kugel- just to be clear, silly relates to ideas or suggestions, not you yourself.

And to be clear about what might be cultural context, "silly" is used as a single word to represent the phrase "does not make sense in the current context".

However one thing that does relate to you is the approach and attitude. You come across as very aggressive and demanding.
That may be a language proficiency thing, but your English is generally good so its hard not to make that interpretation. You also say a lot of "I want" "I use" ignoring the fact that many others want and use different things, I could just as easily say "All I care about is C++ symbols working accurately, who cares about TM". This approach will get us nowhere. Neither you nor I "own" the project.

And an aggressive response targeting niche or corner cases is very disheartening to those who have spent their time to propose a significant improvement of core features.

Note, @techee has made every function that uses LSP configurable, so if its not supported by the server it can fall back to TM or be disabled by the user.

This is why I want to keep TM infrastructure working and consistent when LSP is in effect.

Please propose how you will make synchronous TM work with asynchronous LSP servers. There is a fundamental divide which is why @techee handled it by having individual user facing functions use either TM or LSP, they have to adapt to the API paradigm, asynchronous LSP is not a drop in replacement of synchronous TM.

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

This is one of the silly statements, to have a function you need either a ctags parser or an LSP server that supports it. If the language has an LSP server the available set of capabilities will always be better than no ctags parser.

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

Yes it is hard to understand, please detail your use-case.

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.

C'mon, thats a poor excuse, the readme on geany-lsp tells you sudo apt install clangd and the other supported servers. You have several times said to others "Why don't you just try it" in relation to your own PRs so it seems reasonable for others to expect the same from you.

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

@kugel- reply: We don't have to deep dive into that. I just made up an example that doesn't have a specialized LSP interface.

Making up blue sky functionality that Geany does not support as a reason to attack a PR is not acceptable, it is simply disruptive behaviour that adds nothing to the discussion. Please do not do it again. If you want to propose blue sky then do it on #3675.

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.

Ok, "AST or other means" although in reality thats what they do. But my point was that the server has some form of additional information that TM does not support and so provides answers to the questions with an accuracy that TM cannot. The whole point of this PR is to allow the use of LSP servers to get that accuracy, exporting lower accuracy information to TM and then expecting it to answer the question is a silly idea.

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.

Nobody said that, and its no different to Scintilla lexers or ctags parsers the Geany project does not maintain.

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