blackdrag commented on PR #2936: URL: https://github.com/apache/groovy/pull/2936#issuecomment-5725576642
Sorry for taking a while, but this topic here broad and it took me a while to do some research. And you made further changes anyway. > It does not try to match the IDE-shaped servers on GDSL, joint Groovy+Java compilation, cross-language rename, Gradle/Maven invocation, a debugger, or a test runner. Those are real strengths of the other implementations; they are out of scope here on purpose. The differentiator is “same compiler as the language, small surface, safe edits,” not “more IDE features.” I think it is a healthy approach to not to try to solve these. But again I am wondering about "its role being". You say no `joint Groovy+Java compilation`, but you do have joint compilation in there. It is just no joint compilation dictated by the IDE or tooling outside the LS. You seem to want to enable things as they are possible on the compiler level. Which is I think a good approach, but then you also have this extension mechanism. First of all I am questioning why the LS uses that itself. I get that you want to enrich the code with more semantic information, which is normally not in there, because it is supposed to be resolved at runtime. Which means the direct method call targets you actually set there are potentially not the actual targets. Which is... well, something we have to live with I guess. Of course a completion with a selection of a method could actually select the real target, but then this information is lost later. My "pain point" here is that you use the extension mechanism for this and this is probably also the only reason the extension mechanism exists. Also to do th is no extension mechanism is actually needed I would say. If I am wrong here, then I would like to hear more. Your vision was not giving much information in that respect - only a groovy-mcp, for which I currently fail to see the need of an extension mechanism. Well to make things shorter: * IDE usage: groovy-lsp will most probably have performance problems with anything but a small project. Tooling environment and groovy-lsp can differ a lot. For example for custom compiler configurations, special class paths and so on. At the same time it does not replace a more serious plugin that supports cross-language renames for example. So using it in an IDE is possible, but limited. For people that want a more lean IDE probably nice, but for those this lsp itself may be too heavy. * usage in other lsp projects is for similar reasons limited. * What is the extension mechanism actually for? Using multiple extensions we may run into problems of ordering and other problems. It is something to maintain. And it is currently only useful to the semantic enriching you added, which does not have to be an extension at all imho. * Maybe it could replace Prominic groovy-language-server * trustytrojan/groovyls is I think originally a fork of it, but I am not really seeing that or other LSPs for groovy using this groovy-lsp as base at the moment. I have trouble seeing the resuse case in other LSPs Again, do not get me wrong. I am not pushing back on the PR idea in general. I am trying to work the picture out. The picture of what this PR wants to be and what it does not want to be. Only after I have a sharp image I can actually see if the PR goes in that direction or not. If for example the idea is "just" a groovy-mcp, then I would drop the extension mechanism. Which is a suggestion I would only be able to do once I have a more complete and sharper picture. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
