Tim Oh yes. There are still part of Pharo that we did not clean.
Stef On Fri, Sep 1, 2017 at 1:39 PM, Tim Mackinnon <tim@testit.works> wrote: > 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 >> >> >
