Hi,

As you could see in the Pillar highlighting support, Rubric can now handle
any syntax highlighting in a rather straightforward way. You can also
easily embed this in a Glamour browser.

You can see the example in the GT-InspectorExtensions-Pillar. You can load
the code in a Moose image like this:
Gofer new
        smalltalkhubUser: 'Pier' project: 'Pillar';
        configuration;
        loadStable.
Gofer new
       smalltalkhubUser: 'JanKurs' project: 'PetitParser';
       configurationOf: #PetitParserIslands;
       load.
#ConfigurationOfPetitParserIslands asClass loadDevelopment.
Gofer new
       smalltalkhubUser: 'Moose' project: 'GToolkit';
       package: 'GT-InspectorExtensions-Pillar';
       load.

Cheers,
Doru



On Fri, Sep 5, 2014 at 4:28 PM, Thierry Goubier <thierry.goub...@gmail.com>
wrote:

>
>
>
> 2014-09-05 16:03 GMT+02:00 p...@highoctane.be <p...@highoctane.be>:
>
>> Maybe we can start small.
>>
>> I've current needs that could well be handled in the environment.
>>
>> The FileBrowser is in my view quite not used enough.
>>
>> When doing web applications, I deal with Javascript, CSS, content files
>> etc all the time.
>>
>> The FileBrowser allows to edit files in its content pane.
>> Doing an Accept (Alt-S) on the pane saves the file.
>>
>> So, instead of starting an external edit session in Vim, I mostly work
>> there for some smaller changes (like tweaking CSS).
>>
>> Now, if we could have a syntax highlighter in there it would be nice.
>>
>
> Yes. Anybody knows what is the API for adding / changing the styler on a
> text morph? I'll have a use for a SmaCC grammar styler as well.
>
> Anybody has a CSS parser around?
>
> Thierry
>
>
>>
>> For CSS it wouldn't be too damn hard I think.
>>
>>
>> Phil
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 5, 2014 at 3:35 PM, Jan Vrany <jan.vr...@fit.cvut.cz> wrote:
>>
>>> Hi Torsten, Phil,
>>>
>>> On Thu, 2014-09-04 at 14:18 +0200, Torsten Bergmann wrote:
>>> > Hi Phil,
>>> >
>>> > if there is something I would like to see our Pharo ecosystem and ST
>>> in general moving
>>> > towards is to such a "multilanguage"/"multisourcecode"/"flexible
>>> ressources" kind of
>>> > thing. Even when this could not be a short term goal I would like to
>>> see this
>>> > in the long term.
>>>
>>> I've been working in this area for many years now. And have learned a
>>> good deal while doing that :-)
>>> Making one language to execute within other's environment is the easy
>>> part, though it could be a lot of work (especially, if you care about
>>> performance). Making tools to be aware of different languages is not
>>> hard too, thought it is "just" a huge amount of work that has to be
>>> done. The tricky part is to allow one to talk to each other, preserving
>>> each other's semantics and still stay intuitive, clear and free of
>>> unnecessary boilerplate code. Another tricky bit is to make other
>>> workflows and ways of coding things in other languages work nicely with
>>> the way Smalltalk way we do it in Smalltalk. These are tough bits.
>>> That's where a real research has yet to be done...
>>>
>>> >  - running Java inside of Smalltalk/X
>>>
>>> Well, Smalltalk/X can do much more with Java than "just" run it.
>>> Java has been fully integrated into development tools supporting full
>>> development cycle :-)
>>>
>>>
>>>
>>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Reply via email to