[
https://issues.apache.org/jira/browse/GROOVY-12411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18115360#comment-18115360
]
ASF GitHub Bot commented on GROOVY-12411:
-----------------------------------------
blackdrag commented on PR #2936:
URL: https://github.com/apache/groovy/pull/2936#issuecomment-5672874644
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.
> Add a first-party Language Server Protocol implementation (groovy-lsp)
> ----------------------------------------------------------------------
>
> Key: GROOVY-12411
> URL: https://issues.apache.org/jira/browse/GROOVY-12411
> Project: Groovy
> Issue Type: Improvement
> Reporter: Daniel Sun
> Priority: Major
>
> Ship an optional first-party language server so editors can offer Groovy
> completion, navigation, diagnostics, and refactorings against the in-tree
> compiler rather than a community fork.
> h3. Why
> Community servers ({{groovy-language-server}}, {{gvy}}/{{gls}}) lag language
> changes. A module in this repository compiles with the same
> {{CompilationUnit}} the rest of Groovy uses, so parser and type-system work
> land in the IDE automatically.
> h3. What to ship
> * New optional subproject {{groovy-lsp}} (not part of {{groovy-all}})
> * {{groovylsp}} / {{groovylsp.bat}} launchers (stdio JSON-RPC; optional
> {{--socket}})
> * LSP 3.18 over Eclipse LSP4J 1.0; unknown 3.19 fields ignored
> * Compile open buffers through {{SEMANTIC_ANALYSIS}} (no class generation)
> * Identifier name spans on {{AnnotatedNode}} so rename/highlight select the
> name, not the whole declaration (same 1-based code-point columns as
> GROOVY-12085)
> h3. Language features (advertise only what is implemented)
> * Incremental sync, push/pull diagnostics
> * Completion (keywords, snippets, members, workspace types with auto-import,
> GDK with a prefix) and {{completionItem/resolve}}
> * Hover, signature help, document highlight
> * Definition, type definition, implementation, declaration, references (by
> declaration identity)
> * Prepare-rename / rename (rename the file when the class name matches the
> file stem)
> * Document and workspace symbols, folding, selection range, semantic tokens,
> inlay hints
> * Organize imports (star, static, alias); unused-import hints
> * Code actions: add import, implement abstracts, insert inferred field type,
> add package from path, create missing class stub, generate accessors /
> {{toString}} / {{equals}}/{{hashCode}} / constructor, add {{@Override}}
> * Call hierarchy and type hierarchy
> * Reference-count code lenses
> h3. Safety and classpath
> * {{@Grab}} and {{@ASTTest}} off unless the client sets {{grapeEnabled}} /
> {{astTestEnabled}}
> * Diagnostics scoped to the owning source unit (shared {{ErrorCollector}})
> * No Gradle or Maven Tooling API; the client supplies {{classpath}} /
> {{sourcePaths}}. If those are empty, fall back to {{src/main/groovy}} (and
> friends) and jars under {{lib}} / {{libs}}
> * Unchanged inputs skip recompilation; {{GroovyClassLoader}} is reused and
> closed on shutdown
> h3. Out of scope
> * Debugger (DAP)
> * Test runner
> * Invoking Gradle or Maven to resolve the project
> h3. How to run
> {code}
> groovylsp
> {code}
> Optional flags: {{\-\-stdio}} (default), {{\-\-socket port}}, {{\-\-help}},
> {{\-\-version}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
