Overriding the text styler

> I've been looking at what it would take to add syntax
> highlighting/coloring for<package I've already spent too much time
> talking about>  and think I have a better understanding of what's
> involved.
>
> Basically, there needs to be a level of indirection added similar in
> concept to compilerClass.  However, since the Squeak doesn't appear to
> have been designed with a modular text styler in mind it's not going to
> be as nice and neat (at least not right away.)  InnerTextMorph appears
> to be where the styling actually occurs and it in turn depends on
> SHTextStylerST80 to do the work which is directly hard-coded in 5 places
> in the image.  At the very least there would need to be a global setting
> that can be overridden which would default to SHTextStylerST80.  This
> could be done via a class method (on Object or somewhere else in the
> hierarchy?) or probably better would be a preference setting that would
> define the default styler.  From there, there would need to be one of
> the following:
>
> 1) A per-text object being styled check to determine what styler to use
> (i.e. in the code browser there would need to be a check of what class
> you're styling for, and for other standalone text morphs you'd need to
> override as needed)
>
> 2) Anyone wanting to customize styling would need to completely take
> over styling everywhere and deal with use cases like mine dynamically in
> their custom styler internally.
>
> While I'll take any accommodations I can get for my needs, I'm thinking
> it would be pretty cool to have more modular styler setup in the various
> code browsers.  In a Smalltalk-only world it would allow you to play
> around with changes to the styler in a safer manner (i.e. if you could
> have it only apply to a specific class hierarchy, your other browser
> windows would continue to work properly while you're writing/debugging
> it).  But it could also be handy if at some point we wanted to support
> something fancy like StyledTextEditor or Markdown for package/class
> comments.  And of course there's my use case where your OMeta/Lisp/DSL
> code could be nicely styled as a first-class citizen just like Smalltalk
> code in the browser... but also in workspaces (i.e. you could have
> multiple DSL-specific, styled workspaces providing live interaction...
> how cool would that be?)
>
> Seems like a nice feature to have... what do you think?  If this is
> agreeable, I'm fine doing the work on the first cut at this.  I just
> need to know how I should handle the top level indirection and whether I
> should be going for an all-or-nothing monolithic approach (i.e. global
> replacement of the styler for everything) or keeping a modular approach
> in mind at the cost of a bit more complexity?
>
> Thanks,
> Phil

> Hi Phil,
>
> On 6/11/2015 10:11 PM, Phil (list) wrote:
> > I've been looking at what it would take to add syntax
> > highlighting/coloring for<package I've already spent too much time
> > talking about>  and think I have a better understanding of what's
> > involved.
> >
> > Basically, there needs to be a level of indirection added similar in
> > concept to compilerClass.  However, since the Squeak doesn't appear to
> > have been designed with a modular text styler in mind it's not going to
> > be as nice and neat (at least not right away.)  InnerTextMorph appears
> > to be where the styling actually occurs and it in turn depends on
> > SHTextStylerST80 to do the work which is directly hard-coded in 5 places
> > in the image.  At the very least there would need to be a global setting
> > that can be overridden which would default to SHTextStylerST80.  This
> > could be done via a class method (on Object or somewhere else in the
> > hierarchy?) or probably better would be a preference setting that would
> > define the default styler.  From there, there would need to be one of
> > the following:
> >
> > 1) A per-text object being styled check to determine what styler to use
> > (i.e. in the code browser there would need to be a check of what class
> > you're styling for, and for other standalone text morphs you'd need to
> > override as needed)
> >
> > 2) Anyone wanting to customize styling would need to completely take
> > over styling everywhere and deal with use cases like mine dynamically in
> > their custom styler internally.
> >
> > While I'll take any accommodations I can get for my needs, I'm thinking
> > it would be pretty cool to have more modular styler setup in the various
> > code browsers.  In a Smalltalk-only world it would allow you to play
> > around with changes to the styler in a safer manner (i.e. if you could
> > have it only apply to a specific class hierarchy, your other browser
> > windows would continue to work properly while you're writing/debugging
> > it).  But it could also be handy if at some point we wanted to support
> > something fancy like StyledTextEditor or Markdown for package/class
> > comments.  And of course there's my use case where your OMeta/Lisp/DSL
> > code could be nicely styled as a first-class citizen just like Smalltalk
> > code in the browser... but also in workspaces (i.e. you could have
> > multiple DSL-specific, styled workspaces providing live interaction...
> > how cool would that be?)
> >
> > Seems like a nice feature to have... what do you think?  If this is
> > agreeable, I'm fine doing the work on the first cut at this.  I just
> > need to know how I should handle the top level indirection and whether I
> > should be going for an all-or-nothing monolithic approach (i.e. global
> > replacement of the styler for everything) or keeping a modular approach
> > in mind at the cost of a bit more complexity?
> >
> > Thanks,
> > Phil
>
> I think we should properly support your use case, and the possibility of
> DSL workspaces with specific stylers.
>
> Do you have a working OMeta Styler?
>

> Juan,
>
> On Fri, 2015-06-12 at 09:10 -0300, Juan Vuletich wrote:
> > Hi Phil,
> >
> > I think we should properly support your use case, and the possibility of
> > DSL workspaces with specific stylers.
> >
> > Do you have a working OMeta Styler?
> >
>
> Not yet...
>
> > If you have at least a barely working one, we'll work out the proper
> > styler selection for each code editor. Please don't work too much on the
> > styler selection, Once we have more than one styler, I'd like to
> > experiment with this a bit, and I don't want to risk you wasting too
> > much effort before we agree on how to do it.
> >
>
> That's all I needed to hear.  I will get an OMeta styler working ASAP so
> that we have something to play around with.  Initially I'll take the
> same approach that it uses for the compiler: use the same API as the
> existing Smalltalk styler.
>

> On Fri, 2015-06-12 at 14:12 -0400, Phil (list) wrote:
>> Juan,
>>
>> On Fri, 2015-06-12 at 09:10 -0300, Juan Vuletich wrote:
>> > Hi Phil,
>> >
>> > I think we should properly support your use case, and the possibility of
>> >
>> > DSL workspaces with specific stylers.
>> >
>> > Do you have a working OMeta Styler?
>> >
>>
>> Not yet...
>>
>> > If you have at least a barely working one, we'll work out the proper
>> > styler selection for each code editor. Please don't work too much on the
>> >
>> > styler selection, Once we have more than one styler, I'd like to
>> > experiment with this a bit, and I don't want to risk you wasting too
>> > much effort before we agree on how to do it.
>> >
>>
>> That's all I needed to hear.  I will get an OMeta styler working ASAP so
>> that we have something to play around with.  Initially I'll take the
>> same approach that it uses for the compiler: use the same API as the
>> existing Smalltalk styler.
>>
>
> OK, I now have a minimally functioning styler for OMeta (at least in the
> code browser).  It's an elegant yet manual, force-fit, hack-and-slash
> job: I've overridden the handful of methods that reference
> SHTextStylerST80 to use a global variable containing the styler to use
> and can alternate between the two stylers before opening a code browser
> window.  It's one or the other right now: either you're using the
> existing styler and only Smalltalk code gets styled or you're using my
> new styler and only the OMeta code gets styled.  Is this far enough
> along that you'd want to start playing with it?  If so, I'll mop up a
> bit and push out to github.
>
>> > Cheers,
>> > Juan Vuletich
>>
>> Thanks,
>> Phil
>
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

> On 6/17/15, Phil (list) <[hidden email]> wrote:
> > On Fri, 2015-06-12 at 14:12 -0400, Phil (list) wrote:
> >> Juan,
> >>
> >> On Fri, 2015-06-12 at 09:10 -0300, Juan Vuletich wrote:
> >> > Hi Phil,
> >> >
> >> > I think we should properly support your use case, and the possibility of
> >> >
> >> > DSL workspaces with specific stylers.
> >> >
> >> > Do you have a working OMeta Styler?
> >> >
> >>
> >> Not yet...
> >>
> >> > If you have at least a barely working one, we'll work out the proper
> >> > styler selection for each code editor. Please don't work too much on the
> >> >
> >> > styler selection, Once we have more than one styler, I'd like to
> >> > experiment with this a bit, and I don't want to risk you wasting too
> >> > much effort before we agree on how to do it.
> >> >
> >>
> >> That's all I needed to hear.  I will get an OMeta styler working ASAP so
> >> that we have something to play around with.  Initially I'll take the
> >> same approach that it uses for the compiler: use the same API as the
> >> existing Smalltalk styler.
> >>
> >
> > OK, I now have a minimally functioning styler for OMeta (at least in the
> > code browser).  It's an elegant yet manual, force-fit, hack-and-slash
> > job: I've overridden the handful of methods that reference
> > SHTextStylerST80 to use a global variable containing the styler to use
> > and can alternate between the two stylers before opening a code browser
> > window.  It's one or the other right now: either you're using the
> > existing styler and only Smalltalk code gets styled or you're using my
> > new styler and only the OMeta code gets styled.  Is this far enough
> > along that you'd want to start playing with it?  If so, I'll mop up a
> > bit and push out to github.
> >
> >> > Cheers,
> >> > Juan Vuletich
> >>
> >> Thanks,
> >> Phil
> >
> >
> >
> > _______________________________________________
> > Cuis mailing list
> > [hidden email]
> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

> On Fri, 2015-06-12 at 14:12 -0400, Phil (list) wrote:
> > Juan,
> >
> > On Fri, 2015-06-12 at 09:10 -0300, Juan Vuletich wrote:
> > > Hi Phil,
> > >
> > > I think we should properly support your use case, and the possibility of
> > > DSL workspaces with specific stylers.
> > >
> > > Do you have a working OMeta Styler?
> > >
> >
> > Not yet...
> >
> > > If you have at least a barely working one, we'll work out the proper
> > > styler selection for each code editor. Please don't work too much on the
> > > styler selection, Once we have more than one styler, I'd like to
> > > experiment with this a bit, and I don't want to risk you wasting too
> > > much effort before we agree on how to do it.
> > >
> >
> > That's all I needed to hear.  I will get an OMeta styler working ASAP so
> > that we have something to play around with.  Initially I'll take the
> > same approach that it uses for the compiler: use the same API as the
> > existing Smalltalk styler.
> >
>
> OK, I now have a minimally functioning styler for OMeta (at least in the
> code browser).  It's an elegant yet manual, force-fit, hack-and-slash
> job: I've overridden the handful of methods that reference
> SHTextStylerST80 to use a global variable containing the styler to use
> and can alternate between the two stylers before opening a code browser
> window.  It's one or the other right now: either you're using the
> existing styler and only Smalltalk code gets styled or you're using my
> new styler and only the OMeta code gets styled.  Is this far enough
> along that you'd want to start playing with it?  If so, I'll mop up a
> bit and push out to github.
>
> > > Cheers,
> > > Juan Vuletich
> >
> > Thanks,
> > Phil
>

> Hi Phil,
>
> On 6/22/2015 9:13 PM, Phil (list) wrote:
> > Juan,
> >
> > I saw the changes you committed over the weekend and pulled down the
> > latest to have a spin.  The textStylerClass approach addresses the
> > dynamic styler use case nicely.
> >
> > Thanks,
> > Phil
>
> Yes. I was a bit busy and couldn't comment on this, but yes. Now we can
> have specific text stylers and autocompleters. I played a bit with
> OMeta2 and it seems to work ok. The remaining issue is that it is class
> based. For classes that have both OMeta and Smalltalk methods, we always
> use the OMeta styler... Is there a way for the compiled method to know
> if it is in Smalltalk or in OMeta? If the answer is yes, then this can
> also be fixed.
>