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"