groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Milles, Eric (TR Tech, Content & Ops)" <eric.mil...@thomsonreuters.com>
Subject Re: [editor/tooling support in core groovy]
Date Sun, 17 Feb 2019 20:16:19 GMT
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.milles@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 <blackdrag@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

Mime
View raw message