Hi Tim. Currently commands are loaded after rubric. So RubSmalltalkEditor can't use them directly.
2018-08-21 13:03 GMT+01:00 Tim Mackinnon <tim@testit.works>: > AH - this makes sense then that SystemCommands is in its own Repo then > (although all these tiny repos get quite difficult the track so you can > understand where/how to contribute). > > This leads to another question - if I stick my commands for extend > selection and jump to keyword in SystemCommands - is the load order such > that RubSmalltalkEditor can safely access those commands (I know that for > Calypso its ok, but can I reference those commands in the older > RubSmalltalkEditor). Otherwise I will need to put the guts of my commands > in the RubSmalltalkCodeMode which is shared by al editors (but it feels a > bit too generic place for textMorph navigation stuff). > > Tim > > > > On 21 Aug 2018, at 05:48, Esteban Lorenzano <esteba...@gmail.com> wrote: > > Hi, > > On 20 Aug 2018, at 00:39, Denis Kudriashov <dionisi...@gmail.com> wrote: > > > 2018-08-19 23:12 GMT+01:00 Tim Mackinnon <tim@testit.works>: > >> Thanks Denis - I guess for now I can put the methods in >> RubSmalltalkEditor so that the playground can operate and then my Calypso >> plugins can also reference that code too (if class methods). >> >> Is the idea that playground will become part of Calypso too? >> > > No. > What we can try to achieve is to reused Commander everywhere. So these > SystemCommands will be reused by different tools. > > > Yes, this is what we are targeting, to have a centralised command library > that manages all system commands (so we do not need to duplicate code all > around). > With enough time to implement, all tools will use same command mechanism. > > Esteban > > > >> If so, I can add the methods I need as an extension (although I guess >> this won’t work as the keyboard mapping for playground in one method and >> not extensible like Calypso which uses pragmas). >> >> I’ll do something as a pr and we can figure it out. >> >> It’s worth saying, that for my Calypso plugins I’ve had to abuse your >> mechanism a bit as the simple #execute mechanism doesn’t give me access to >> the text morph to control the cursor. I was able to do it though via the >> prompting mechanism (I just don’t show any ui prompt). >> >> Tim >> >> Sent from my iPhone >> >> On 19 Aug 2018, at 14:28, Denis Kudriashov <dionisi...@gmail.com> wrote: >> >> Hi. >> >> I dont't know answer to your question. But for the note: >> Calypso was needed to override existing way to spawn implementors/senders >> and so on. So I added subclass of RubSmalltalkEditor - ClyTextEditor which >> overrides required methods. >> So if you will put new methods into the RubSmalltalkEditor then Calypso >> will be able to use them. >> >> 2018-08-19 16:55 GMT+01:00 Tim Mackinnon <tim@testit.works>: >> >>> Hi I’m trying to work out the best way to cope with the fact that we are >>> in a hybrid place where the Playground is using an RubSmalltalkEditor but >>> Calypso has its own mechanisms for editing code. >>> >>> I have commands that should/can work in both the playground as well as >>> code method editor (in Calypso). >>> >>> Previously my code lived in RubSmalltalkEditor and Nautilus was using >>> that too - but now I’m not sure where to put some reusable methods that use >>> RBParser and the AST to find the best place to position your cursor. >>> >>> I can make a class method on RubSmalltalkEditor and Calypso commands >>> could reference that (but that feels wrong somehow). I could make some >>> extension methods on RBParser and both places reference that - but then who >>> should own the extension method (as I think RubSmalltalkEditor is lower >>> level and Calypso is then loaded on top). >>> >>> Anyone have some good suggestions? >>> >>> Tim >>> >> >> > > >
