Marcus - I'd be interested in how you thought to solve this. My solution seems to work - but it's not the most elegant. Retrying lots of different ways like I show, smacks a bit of desperation (this said, it is quite compact).
Apart from that - I was actually interested in thoughts on the parse method - the onError naming is a bit misleading compared to other methods in the image. I wonder if it should be called something like "onErrorMerge:" to signal that it's going to reuse the results? Stef - with regards to broken source, my proposed solution reuses what is already there - thus if you highlight specific code, it reverts to the original strategy and tries to compile just that code. This bugs me however - so if you highlight nothing, it tries to compile the source multiple ways, I drop down to chopping the source up to where your cursor is - which seems like a decent cheap strategy. I don't know if our parser is able to recover from simple errors and just have error nodes in the ast, and whether the #bestNodeFor method then ignored error nodes... this is what I think Dolphin used to do. Tim Sent from my iPhone > On 31 Aug 2017, at 19:11, Marcus Denker <marcus.den...@inria.fr> wrote: > > >> On 31 Aug 2017, at 19:07, Stephane Ducasse <stepharo.s...@gmail.com> wrote: >> >> On Wed, Aug 30, 2017 at 9:50 PM, Tim Mackinnon <tim@testit.works> wrote: >>> I’m looking for some feedback on the usage of >>> RBParser>>#parseMethod:onError:. >>> >>> I am looking at ways of improving the way we edit code - and making things >>> work (as least for me - but maybe for everyone) a bit more like IntelliJ >>> where they have some great code operations and very good keyboard support. >>> We are certainly close, but at times feel a bit clumsy - which is a shame >>> as we have far better infrastructure to support equivalent features. So I >>> thought I would have a go. >> >> Excellent!!! >> >> >>> Anyway - step one (which I think I’ve come close on), was to teach >>> senders/implementors to look at the AST so you don’t have to highlight >>> exactly what you want to search on - instead it can infer from your cursor… >>> however my next step was to improve how we can select code to ease >>> refactoring, bracketing etc… >> >> Yes but we have to handle broken code then. >> Did you check how smart suggestions did it for code that compiled? >> > > I looked some weeks ago and made some notes what to do… but I fear this has > to wait for next week, > there is no way that I can do anything till ESUG… > > Marcus
