daniellansun commented on PR #2936: URL: https://github.com/apache/groovy/pull/2936#issuecomment-5681332181
> I am wondering about a few things in this: > > * is the change to 1-base in columns not a breaking change? > * I need a more clear answer to what this is not supposed to solve and what it is supposed to solve. So far I understand only that it does not want to be a complete workspace/IDE solution and it does not support anything but Groovy itself. What it is trying to solve seems to be that the other implementations are lagging behind. But those implementations also implement much more of the IDE concept... especially for specific modes, GDSL support, joint compilation, cross language renames, ... So I am not yet clear what the intended scope and differentiator of this implementation are. > * Let me extend the renames point ... In dynamically typed Groovy, where MethodCallExpression.methodTarget is normally not available, what semantic guarantees are intended for definition, references and rename? The current fallback in NavigationService.resolveMethod() appears to select a method based on receiver type, name and argument count. Is this intentionally a best-effort heuristic, and if so, should operations such as rename avoid making potentially incorrect edits when the target cannot be uniquely determined? A heuristic is good enough for Hover I think, but in case of rename this can be a problem. > * You mention `groovy-language-server`, what about `tomaszrup/groovy-language-server-edt` and `trustytrojan/groovyls`? How do you see this implementation in relation to those? > * What do **you** actually want to use this for? And how should others use it? And more from the IDE-side how are IDEs supposed to use this? Is it even intended for direct use in a IDE? > * What is the **vision** for this? Are other LSP implementations supposed to use this as base, or is this intended to be a standalone Groovy language server? > > Yeah, I know, a wild mix of specific and very broad questions. I am not against the idea at all; I just want to understand more clearly why this PR came into existence in the first place and what you see its role being. Thanks for taking the time to unpack this — the mix of questions is fair, and I should have been clearer about scope from the start. **1-based columns.** That is GROOVY-12085 in the *compiler* AST (1-based Unicode code points). It is not an LSP coordinate change. The protocol stays 0-based in the encoding negotiated at `initialize`; the server converts, and clients never see AST columns. Existing LSP clients do not need to change how they send positions. This module also does not add name-span fields to `AnnotatedNode`; identifier selection for rename/highlight is done in groovy-lsp from the node’s existing source span. **What this is for, and what it is not.** It is a Groovy *language core* for LSP, not a workspace/IDE. It is meant to stay current with the in-tree compiler so editors (and later AI tools) get diagnostics, completion, hover, navigation, and conservative rename on `.groovy` sources. 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.” **Rename vs hover when `methodTarget` is missing.** You are right that a name-and-arity fallback is a heuristic, and that it is a problem for rename. That is now the policy: hover may show a unique arity match and mark it `_inferred_`; definition lists every such candidate rather than picking the first; **prepare-rename and rename refuse** unbound dynamic calls. They only run on declarations (by owner + name + descriptor) and on calls/properties the compiler actually bound. A wrong edit is worse than a refused rename. **The other servers.** Prominic `groovy-language-server` is the earlier community server; this is a new implementation, not a fork. `trustytrojan/groovyls` (Apache 2.0) is the natural place for Jenkins GDSL and a forced STC pass — those can sit on this compile/protocol loop later via the incubating `GroovyLspExtension` SPI, without living in this module. `tomaszrup/groovy-language-server-edt` (EPL, JDT + groovy-eclipse) is complementary: joint compilation and Java interop need that stack. We do not copy it, and we do not use its identifier-scan rename fallback. **How to use it.** Yes, it is intended for direct use in an IDE or editor: start `groovylsp` and speak stdio JSON-RPC. The client supplies `groovy.classpath` (we never invoke Gradle or Maven). The same process is the semantic backend for Groovy-aware AI; a later `groovy-mcp` is expected to wrap it so a model can ask what an identifier is without embedding the compiler. **Vision.** Both: a standalone first-party Groovy language server that an editor can run today, and a small compile + protocol loop that other *Apache-2.0* Groovy LSPs (and groovy-mcp) can extend instead of forking. It is not a replacement for the JDT/groovy-eclipse stack, and it will not grow into a full IDE. Happy to go further on any of these if that still feels thin. -- 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]
