- Pharo-users - lists.pharo.org

Re: [Pharo-users] [DesktopManager] Ctlr - D (do-it) is blocked after installation of desktop manager

by Ben Coman

On Tue, Sep 5, 2017 at 5:41 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > On 9/5/17, Torsten Bergmann <astares(a)gmx.de> wrote: > >>How can I de-activate the ctrl-D shortcut for the Desktop manager for > >>the time being? > > > > By not using DesktopManager. > > Sure... > > What I was asking for: How can I use it _without_ the ctrl-D short > cut. Or how can I replace the ctrl - D shortcut with another short > cut. > > >The shortcut handlers are installed upon load > > initialize. > > > And how can I bypass or adapt this initialize method? > You can find pertinent methods like this... (RPackageOrganizer default packageNamed: 'Balloon') definedClasses flatCollect: [ :c | c class methods select: [:m| m selector = #initialize ] ] The rough way would be to edit them how you like and save the package locally, then when you load that into a fresh image it runs how you like. More elegant might be setting a flag with startup actions which the #initialize looks for, and contribute that mod back to the original repo. > > What is the initialization code in case I load the classes manually? > > I'm not sure whether the class-side-initialize methods are run only when Monticello loads a class, or also when loading via changesets or file-in. You could experiment. cheers -ben

Sept. 8, 2017

Re: [Pharo-users] Teapot and Websockets

by Georges

I added two methods: Teapot>>WS: patternActionAssoc self addRouteMethod: (TeaMethodMatcher exactly: #GET) pattern: patternActionAssoc key action: (ZnWebSocketDelegate map: patternActionAssoc key to: patternActionAssoc value) ZnWebSocketDelegate>>teaEvalActionOnRequest: aTeaRequest ^self handleRequest: aTeaRequest When I do: Teapot on GET: '/ws-echo-client' -> ZnWebSocketEchoHandler clientHtml; WS: '/ws-echo' -> ZnWebSocketEchoHandler new; start. And go to localhost:1701/ws-echo-client in my webbrowser I get: WebSocket Test ws://localhost:1701/ws-echo CONNECTED SENT: WebSocket rocks RESPONSE: WebSocket rocks DISCONNECTED To avoid the WS: message: Teapot on GET: '/ws-echo-client' -> ZnWebSocketEchoHandler clientHtml; GET: '/ws-echo' -> (ZnWebSocketDelegate map: '/ws-echo' to: ZnWebSocketEchoHandler new); start For now I will use the WS: message, and hopefully in the future you come with a nice solution :) Georges -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 8, 2017

Re: [Pharo-users] BlockStyler: Make Blocks more recognizable in source code

by Manuel Leuenberger

Hi Cyril, There already is a setting to set the color with alpha: > On 8 Sep 2017, at 08:37, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > > On jeu. 7 sept. 2017 at 18:16, Manuel Leuenberger <leuenberger(a)inf.unibe.ch <mailto:leuenberger@inf.unibe.ch>> wrote: > Well, it has something similar now: > > > > > Hi, > > I would like to get the ratio of "darkening"/"lightening" as a setting if possible. I find the change of color a little abrupt but since it is a personal taste I would like to customize only for myself. So a setting could be cool. > > Else, this is a really cool plugin :) I'll definitively use it. > > -- > Cyril Ferlicot > https://ferlicot.fr <https://ferlicot.fr/> > > http://www.synectique.eu <http://www.synectique.eu/> > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > <highlight.png>

Sept. 8, 2017

Re: [Pharo-users] BlockStyler: Make Blocks more recognizable in source code

by Alistair Grant

Hi Manuel, Thanks very much for making this available and taking the trouble to get it working with the light theme as well. On Fri, Sep 08, 2017 at 06:37:12AM +0000, Cyril Ferlicot wrote: > > On jeu. 7 sept. 2017 at 18:16, Manuel Leuenberger <leuenberger(a)inf.unibe.ch> > wrote: > > Well, it has something similar now: > > [cid] > > > Hi, > > I would like to get the ratio of "darkening"/"lightening" as a setting if > possible. I find the change of color a little abrupt but since it is a personal > taste I would like to customize only for myself. So a setting could be cool. > > Else, this is a really cool plugin :) I'll definitively use it. I was about to send exactly the same email. When I first looked at the plugin with the dark theme (which I can't use, as I can't see it clearly) the colour change seemed to be less pronounced, but in the light theme, as Cyril says, it is too big a change. Thanks again, Alistair

Sept. 8, 2017

Re: [Pharo-users] BlockStyler: Make Blocks more recognizable in source code

by Cyril Ferlicot

On jeu. 7 sept. 2017 at 18:16, Manuel Leuenberger <leuenberger(a)inf.unibe.ch> wrote: > Well, it has something similar now: > > Hi, I would like to get the ratio of "darkening"/"lightening" as a setting if possible. I find the change of color a little abrupt but since it is a personal taste I would like to customize only for myself. So a setting could be cool. Else, this is a really cool plugin :) I'll definitively use it. > > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Sept. 8, 2017

Re: [Pharo-users] Pharo 6.0 Generating Ruby-on-Rails Applications

by Stephane Ducasse

Hi peter About magritte, feel free to extend it and let us know. stef On Thu, Sep 7, 2017 at 2:54 PM, Peter Fisk <peter.fisk(a)gmail.com> wrote: > Hi everyone, The RailsExpress.com website will be updated over the coming > days to reflect what I am currently working on in Pharo 6.0. I have found > that the "Smalltalk like" environment in Ruby isn't powerful enough to > implement a fully automated web application generator. That is why I changed > to Pharo a couple of weeks ago - progress using Pharo has been incredibly > fast. So, my primary focus from now on will be development using Pharo on my > Macintosh. The "Smalltalk like" environment in Ruby actually uses an > interpreter (written in Ruby) that was designed to run Smalltalk byte codes. > It would be trivial to run Smalltalk instead of Ruby using the framework. > The rational for running Ruby instead of Smalltalk was to make it more > accessible to Ruby-on-Rails developers. An interesting fact is that the > Ruby/Smalltalk interpreter is already running nicely on the web (in a Rails > environment using Qooxdoo libraries for the GUI) and also running on my Mac > using JRuby with a Java Swing GUI. And it could be used with some > modifications to run Smalltalk in the same environments. My goal is to build > an "AI" that can automate most of the work that web developers do. Smalltalk > is the only environment that I know of that can implement such an AI in a > short period of time. BTW, I have read the material about Pier and Magritte > which is very interesting, especially in regards to the DSL. My approach to > building the GUI has been to model the Qooxdoo class structure in Smalltalk > and use the Smalltalk objects to build the required code when I send them a > "renderOn: aStream" message. I will be posting more Pharo related > information on my Rails Express Quora blog. Regards, -- Peter > ________________________________ > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Sept. 8, 2017

Re: [Pharo-users] BlockStyler: Make Blocks more recognizable in source code

by Stephane Ducasse

Alain did it in the process browser. On Thu, Sep 7, 2017 at 3:54 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Thank you! > > This is really useful in the context of Seaside render blocks. > > How hard would it be to also add vertical "lines" at the sides like in the > following screenshot: > [image: ImÃ¡genes integradas 1] > > > Best regards! > > > El sept. 6, 2017 8:53 AM, "Manuel Leuenberger" <leuenberger(a)inf.unibe.ch> > escribiÃ³: > >> Hi everyone, >> >> I built a little syntax highlighting extension for the Nautilus source >> code pane, which puts a background color behind blocks, so that nested >> blocks are easily recognizable. >> >> >> Install with: >> >> Metacello new >> baseline: 'BlockStyler'; >> repository: 'github://maenu/BlockStyler/repository'; >> load >> >> GitHub: https://github.com/maenu/BlockStyler >> >> Doesnât work with âFormat as you readâ, just as the IconStyler. If >> anybody has an idea how to integrate it properly into Nautilus as a plugin, >> let me know. Currently itâs an ugly meta-link hack to get access to the >> sourceTextModel. >> >> Cheers, >> Manuel >> >

Sept. 8, 2017

Re: [Pharo-users] Spec "bindings"

by Stephane Ducasse

I like the idea about your extension. We should really get it so that we understand it. >> > countLabel initializeSubject: subject countHolder >> > > > You're welcome. Thank you very much for your time--it's helpful to know > there probably isn't some sophisticated wizardly way to do this that I am > not even able to see or comprehend! :) > > >> >> >> > Then, instead of adding a LabelModel to a ComposableModel, you could add >> > something like a NumberPresenter and specify the spec you want to use >> > (which >> > would in turn display the desired widget). >> > I didn't go that far yet, and created a NumberLabelModel for my example >> > above. It worked, but seems like the wrong way to go about it. Or maybe >> > you >> > need both...I'm not sure! >> > >> > I also want to take a look at self-updating complex widgets as well >> > (lists, >> > tables, etc...) so that telling a list presenter it's list means that >> > adding >> > a value to that list could automatically update the widget and so on. >> > I had some crude prototyping success with that in VW before deciding >> > (hopefully for the last time) that "native" widgets aren't as important >> > to >> > me as a solid and simple way to connect a model to a UI presentation. >> >> >> > This seems much easier to achieve in Pharo, and after years of >> > intermittent >> > attempts I am hopeful that my knowledge level has finally become >> > sufficient >> > to contribute something to this heroic effort. >> >> Superb. >> >> We are discussing with peter (but EsUG is so intense and I should >> finish the lectures for real now that I do not have the braincells) >> about a pragma driven to declare menus because this is a real lack. > > > Good luck! > >> >> >> >> What I suggest is >> - Please please continue your experiment. >> - It would be great if we can compare some typical examples. >> - After that we can take a decision and improve/modify Spec >> and update the documentation. > > > That's a really good idea since I am no Spec expert! I can probably make a > few things work the way I'd like them to, though, in order to produce some > typical examples like master-detail lists and so on. Yes excellent. > >> >> I want to write a small interface for a small app. >> I checked my code >> and I thought that it was strange that we cannot initialize presenter >> once the model is done > > > Right...you can see in Spec that each type of widget creates a static > ValueHolder ( such as '' asValueHolder ) for each type of widget and does > not currently offer a method to swap it out with a new one. yes this is not really good. > > Also, there are probably more available Morphic widgets that could be > adapted (like a progress bar as an number presenter, for example). > >> >> >> GameListModel new >> on: GameCollector smallCollection; >> openWithSpec >> >> >> "protocol: #initialization" >> >> initializeWidgets >> listModel := self newList. >> listModel items: (collector collectionNamed: #owned) >> >> and then back then I realized that I was wrong. To fit Spec (but Spec is certainly too limited) > > > It would be interesting to hear the arguments against lists and trees > updating themselves when their underlying objects change. It looks like > Spec, VW, and Pharo all require you to monitor and replace the UI list when > something is updated. mistake :) Lack of analysis. We are learning while doing it so let us continue. > >> >> >> Stef >> >> thanks for this discussion. > > > You're very welcome. > > Take care, > > Rob > >> >> >> > >> > Take care, >> > >> > Rob >> > >> > On Tue, Sep 5, 2017 at 6:08 PM, Stephane Ducasse >> > <stepharo.self(a)gmail.com> >> > wrote: >> >> >> >> Rob >> >> >> >> Spec deserves another pass. >> >> I see your point with showOn: now I do not see how you could avoid the >> >> presenter building. But may be I'm not enough into it. >> >> So I'm interested in your feedback. >> >> >> >> Stef >> >> >> >> Stef >> >> >> >> On Tue, Sep 5, 2017 at 8:49 PM, Rob Rothwell <r.j.rothwell(a)gmail.com> >> >> wrote: >> >> > Hello, >> >> > >> >> > I was wondering what more experienced users than myself thought of >> >> > the >> >> > idea >> >> > of an explicit Spec "connection point" to a domain model object >> >> > similar >> >> > to >> >> > Dolphin's "showOn:" method, like: >> >> > >> >> > CounterApp showOn: counter. >> >> > >> >> > This would perhaps trigger something like Dolphin's Presenter>>model: >> >> > message (although I've always found the use of "model" confusing when >> >> > there >> >> > are so many "models" involved.) after the widgets had been created: >> >> > >> >> > ComposableModel>>initializeBindings: anObject >> >> > >> >> > In many cases, if your domain model uses ValueHolders as well (like >> >> > Spec >> >> > does), making a connection could just mean replacing the Spec >> >> > ValueHolder >> >> > with your domain ValueHolder so changes to the domain model would >> >> > automatically propagate to the UI presentation without providing >> >> > explicit >> >> > code in ComposableModel>>initializePresenter. >> >> > >> >> > However, since I am still trying to understand and learn Spec, it's >> >> > quite >> >> > possible I am missing some key point and there are reasons not to >> >> > explore >> >> > this line of thinking! >> >> > >> >> > Thank you, >> >> > >> >> > Rob >> >> > >> >> >> > >> >

Sept. 8, 2017

Re: [Pharo-users] Spec "bindings"

by Rob Rothwell

On Thu, Sep 7, 2017 at 2:12 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi Stef, > > > > I think you are correct and you would still always perform actions like: > > > > initializeWidgets (to create components and sub-components) > > initializePresenter (to define interactions between components) > > > > > > But, there could also be a third initialization step like > > > > initializeSubject: aSubjectModel > > Yes > I do not remember exactlty but I have the impression that I identified > the same problem recently because I wanted to do > > MyApp on: aModel > and I realized that the flow proposed did not let me do it that way (may be > I'm incorrect). > > > That would allow you to initialize the domain model of each component > > relative to your overall model. > > Yes. > > > > Then, by exposing the aspects of your model available for viewing by a > UI as > > ValueHolders, it looks pretty straightforward (for simple objects) to > extend > > Spec to use those ValueHolders so that UI elements can implicitly update > > themselves. > > > > The source of my inspiration is the Dolphin "Better Hello World" > example(s) > > here: > > > > http://object-arts.com/blog/files/better-hello-world.html > > > > > > To try it out, I added a few Spec extensions and tried a little "counter" > > test (like your MOOC example) displayed by a CounterApp (having an > increment > > button, decrement button, and label to show the count) such that > > > > CounterApp showOn: counter > > > > triggers > > > > CounterApp>>initializeSubject: aSubjectModel > > > > subject := aSubjectModel. > > > > countLabel initializeSubject: subject countHolder > > > > This results in replacing the UI label ValueHolder with the Counter's > > "count" ValueHolder. If I had more aspects of my model I wanted to > connect, > > I would do it here, or if I wanted to connect the same thing to multiple > > widgets (like a slider, for example), I would do that here as well. > > > > This allows direct interactions with the Counter model (for example, an > > "increment" button) to be reflected directly by the UI without having to > > explicitly update the value after the interaction or listening for > events. > > > > I'll have to think about it some more, but I think Spec has what it needs > > already to create a nice set of "type presenters" instead of what is > > currently seems more like "widget presenters." > > Indeed. > Thanks a lot for your analysis. > You're welcome. Thank you very much for your time--it's helpful to know there probably isn't some sophisticated wizardly way to do this that I am not even able to see or comprehend! > > > Then, instead of adding a LabelModel to a ComposableModel, you could add > > something like a NumberPresenter and specify the spec you want to use > (which > > would in turn display the desired widget). > > I didn't go that far yet, and created a NumberLabelModel for my example > > above. It worked, but seems like the wrong way to go about it. Or maybe > you > > need both...I'm not sure! > > > > I also want to take a look at self-updating complex widgets as well > (lists, > > tables, etc...) so that telling a list presenter it's list means that > adding > > a value to that list could automatically update the widget and so on. > > I had some crude prototyping success with that in VW before deciding > > (hopefully for the last time) that "native" widgets aren't as important > to > > me as a solid and simple way to connect a model to a UI presentation. > > > > This seems much easier to achieve in Pharo, and after years of > intermittent > > attempts I am hopeful that my knowledge level has finally become > sufficient > > to contribute something to this heroic effort. > > Superb. > > We are discussing with peter (but EsUG is so intense and I should > finish the lectures for real now that I do not have the braincells) > about a pragma driven to declare menus because this is a real lack. > Good luck! > > > What I suggest is > - Please please continue your experiment. > - It would be great if we can compare some typical examples. > - After that we can take a decision and improve/modify Spec > and update the documentation. > That's a really good idea since I am no Spec expert! I can probably make a few things work the way I'd like them to, though, in order to produce some typical examples like master-detail lists and so on. > I want to write a small interface for a small app. > I checked my code > and I thought that it was strange that we cannot initialize presenter > once the model is done > Right...you can see in Spec that each type of widget creates a static ValueHolder ( such as '' asValueHolder ) for each type of widget and does not currently offer a method to swap it out with a new one. Also, there are probably more available Morphic widgets that could be adapted (like a progress bar as an number presenter, for example). > > GameListModel new > on: GameCollector smallCollection; > openWithSpec > > > "protocol: #initialization" > > initializeWidgets > listModel := self newList. > listModel items: (collector collectionNamed: #owned) > > and then back then I realized that I was wrong. > It would be interesting to hear the arguments against lists and trees updating themselves when their underlying objects change. It looks like Spec, VW, and Pharo all require you to monitor and replace the UI list when something is updated. > > Stef > > thanks for this discussion. > You're very welcome. Take care, Rob > > > > > Take care, > > > > Rob > > > > On Tue, Sep 5, 2017 at 6:08 PM, Stephane Ducasse < > stepharo.self(a)gmail.com> > > wrote: > >> > >> Rob > >> > >> Spec deserves another pass. > >> I see your point with showOn: now I do not see how you could avoid the > >> presenter building. But may be I'm not enough into it. > >> So I'm interested in your feedback. > >> > >> Stef > >> > >> Stef > >> > >> On Tue, Sep 5, 2017 at 8:49 PM, Rob Rothwell <r.j.rothwell(a)gmail.com> > >> wrote: > >> > Hello, > >> > > >> > I was wondering what more experienced users than myself thought of the > >> > idea > >> > of an explicit Spec "connection point" to a domain model object > similar > >> > to > >> > Dolphin's "showOn:" method, like: > >> > > >> > CounterApp showOn: counter. > >> > > >> > This would perhaps trigger something like Dolphin's Presenter>>model: > >> > message (although I've always found the use of "model" confusing when > >> > there > >> > are so many "models" involved.) after the widgets had been created: > >> > > >> > ComposableModel>>initializeBindings: anObject > >> > > >> > In many cases, if your domain model uses ValueHolders as well (like > Spec > >> > does), making a connection could just mean replacing the Spec > >> > ValueHolder > >> > with your domain ValueHolder so changes to the domain model would > >> > automatically propagate to the UI presentation without providing > >> > explicit > >> > code in ComposableModel>>initializePresenter. > >> > > >> > However, since I am still trying to understand and learn Spec, it's > >> > quite > >> > possible I am missing some key point and there are reasons not to > >> > explore > >> > this line of thinking! > >> > > >> > Thank you, > >> > > >> > Rob > >> > > >> > > > >

Sept. 8, 2017

Re: [Pharo-users] #parseMethod:onError: isn't as obvious as expected - is it me?

by Tim Mackinnon

Damn you smalltalkâ¦ you suck me in to little side problemsâ¦. RBParser is actually a lot more flexible than I had realised - and not so difficult to understand for a mere mortalâ¦ It naively seems that (what I still consider a confusingly named method) is quite simple to extend to handle at least medium sized errors just by doing something like: ast := [RBParser parseMethod: source onError: [ :msg :pos :parser | |seqNode errorNode| errorNode := RBParseErrorNode errorMessage: msg value: parser currentToken value printString at: pos. seqNode := parser sequenceNodeClass new. parser step; parseStatements: true into: seqNode. seqNode addNodeFirst: errorNode; yourself ]] onDNU: #body: do: [ nil âHandle non method source fragments"]. NOTE: I did have to add >>#currentToken as a method to RBParser as it doesnât expose very much for the onError blocks, which I think it should to make them a bit more useful. Tim > On 7 Sep 2017, at 14:39, Tim Mackinnon <tim(a)testit.works> wrote: > > Thanks Thierry - Iâve been noodling in the background and next I hit the question of âcommentsâ - which I found RB does handleâ¦ and then as per your point - how to skip past an error and try further down (which it seems that the scanner might have the info to let me skip simple things). You seem to get sucked in more and more when trying to to this properly - which does make it sound like a very good internship or GSoc project. > > I think I may have enough to get something polished enough to release to the wider world. I certainly love having better keyboard support when Iâm coding - as we type a lot (even though we have simple syntax) - and having efficient tools takes away the friction. > > Next on my hit list, it add the same support to the refactoring tools - which while sophisticated are so clunky in use when compared to IntelliJ. > > Tim > >> On 7 Sep 2017, at 08:02, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Hi Tim, >> >> 2017-09-01 13:39 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >> 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. >> >> Yes, when you are on a boundary, then finding the right node may be difficult. When developping the ancestor to smart suggestion, I considered #bestNodeFor: as good enough, but I considered looking into "up" and "down" ast navigation at a time, and I wasn't alone (I think it was active in the Pharo editor at a point). >> >> >> 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. >> >> There is a general question there, which is how you try to parse as much as possible while jumping over the error, making the error area as small as possible (that would be really great for syntax highlighting, by the way). >> >> The problem is that in hand-written parsers, you need to hard-code the error management in the parser. With a table-driven parser (as is SmaCC), then you can explore in a systematic way what are the possible states that would allow the parsing to continue correctly after making the error area as small as possible. >> >> This would make for a very nice internship subject... >> >> >> 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. >> >> It is very easy in Pharo to implement a nice and clean keyboard handling; all the necessary components have been in place for years, and we already have implementations (using the KM API). >> >> Now, most Pharo developpers just jump into hardcoding keyboard handling instead. >> >> Thierry >> >> >> 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.goubier(a)gmail.com <mailto:thierry.goubier@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(a)testit.works <mailto: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.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>> > >>> > >>> >> On 31 Aug 2017, at 19:07, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: >>> >> >>> >> On Wed, Aug 30, 2017 at 9:50 PM, Tim Mackinnon <tim(a)testit.works <mailto: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 >>> >>> >>> >> >

Sept. 8, 2017