Thanks Thierry - this is proving an interesting problem domain ... I too am using #bestNodeFor: although I don't find it always gives the best node (it does if you are clearly in the target range, but if you are on the outer boundary like the next position after a selector or next to a "." or ";" it favours the parent and not the closest node. So in usage I find I need to tweak it a bit.
I'll look at smacc though - also there is that experimental setting to allow parse errors, I don't know if it helps in any way. All this said, I think I have a workable suggestion that is not much code that might be open to scrutiny from those wiser than me. Looking at the keyboard handling in the system - it's quite sprawling and tricky to follow. I think there is lots of room for refactoring. I'm also not sure if I like the pragma usage either - I find it quite difficult to follow what's calling what. Tim Sent from my iPhone > On 1 Sep 2017, at 09:18, Thierry Goubier <thierry.goub...@gmail.com> wrote: > > Hi Tim, > > The RB ast has a specific method for finding the right node: in AltBrowser, I > use ast bestNodeFor: aTarget selectionInterval. > > For the second case (parse what is selected), you may want to look into > SmaCC: it has specific entry points (used for refactoring) to try all > possible starts in a parser for a given piece of text and returning all the > possible correct asts. As a hand-writen parser, the RBParser can't do that > unless you add the necessary entry points by hand and hack around the error > handling, because most of the parse attempts end on an error (as they should). > > Regards, > > Thierry > > 2017-09-01 8:50 GMT+02:00 Tim Mackinnon <tim@testit.works>: >> 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 >> >> >
