I believe that's the way to go. I was thinking about it recently (we use a
groovy dsl for a work project and providing a decent editor would be nicer
for the customer, does have very low prio though). I found
https://github.com/palantir/language-servers which is using the groovy
compiler and exposing it as Language Server, but is abandoned. One of the
many great things about using the original compiler would be that you could
also use the extensions. However, especially for DSLs, the autocomplete
would need more information than currently provided. My initial thoughts
are that an ASTNode should be able to contribute to autocomplete and that
we need a context sensitive factory for creating ASTNodes. Have not
implemented anything yet.
Am So., 17. Feb. 2019 um 21:16 Uhr schrieb Milles, Eric (TR Tech, Content &
Ops) :
> There is also the possibility of a consolidated effort on a Language
> Server Protocol implementation for Groovy that would replace the current
> eclipse tooling upon reaching maturity. This would extend to other
> platforms like Visual Studio Code as well.
>
> --
> *From:* Milles, Eric (TR Tech, Content & Ops) <
> eric.mil...@thomsonreuters.com>
> *Sent:* Sunday, February 17, 2019 2:06 PM
> *To:* dev@groovy.apache.org
> *Subject:* Re: [VOTE] Polish the generics type syntax for closure
>
>
> Agreed. I'd be open to a side project to migrate eclipse patches back
> into core. Many of them should be able to make the crossing. There is
> also the possibility of conditional code with some sort of signal that it
> is the IDE, not the compiler or runtime.
>
>
> There are a few other needs for the editor that the core would need to
> provide:
>
>
>1. offsets, not just line and column for AST nodes
>2. parser recovery so incomplete syntax in one method allows the rest
>to be parsed and compiled
>3. remove assumptions of short-lived processes like compiler and allow
>for long-running processes like editor
>
>
> --
> *From:* Jochen Theodorou
> *Sent:* Sunday, February 17, 2019 1:17 PM
> *To:* dev@groovy.apache.org
> *Subject:* Re: [VOTE] Polish the generics type syntax for closure
>
> On 17.02.19 18:31, Milles, Eric (TR Tech, Content & Ops) wrote:
> [...]
> > So, parser recovery is new development. And interpretation of new
> > syntax in the absence of running all AST transforms to completion is new
> > development.
>
> and is there a way to make things more easy? I mean I would prefer to be
> able to give eclipse an unmodified compiler - or at least one that does
> not need to be source patched
>
> bye Jochen
>
