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: [VOTE] Polish the generics type syntax for closure
Date Sun, 17 Feb 2019 20:06:09 GMT
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