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 <blackd...@gmx.org> 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
