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.goubier@gmail.com> wrote:

2014-09-05 16:03 GMT+02:00 phil@highoctane.be <phil@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.vrany@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"