Overriding the text styler

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Overriding the text styler

Phil B
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


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Overriding the text styler

Juan Vuletich-4
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?

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.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Overriding the text styler

Phil B
Juan,

On Fri, 2015-06-12 at 09:10 -0300, Juan Vuletich wrote:

> 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?
>

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.

> Cheers,
> Juan Vuletich

Thanks,
Phil



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Overriding the text styler

Phil B
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
Reply | Threaded
Open this post in threaded view
|

Re: Overriding the text styler

Hannes Hirzel
I think this is a great start to play with.

- elegant
- force-fit

job. Easy to understand.

--Hannes

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
Reply | Threaded
Open this post in threaded view
|

Re: Overriding the text styler

Phil B
Hannes,

On Thu, 2015-06-18 at 12:47 +0000, H. Hirzel wrote:
> I think this is a great start to play with.
>
> - elegant
> - force-fit
>
> job. Easy to understand.
>

OK, you caught me: one of those words probably didn't belong there :-)
That said, I have pushed out the latest to
https://github.com/pbella/OMeta-Cuis and the last section of the README
provides instructions on trying out the new styler.

> --Hannes
>

Thanks,
Phil

> 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



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Overriding the text styler

Phil B
In reply to this post by Phil B
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

On Wed, 2015-06-17 at 03:55 -0400, Phil (list) 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
Reply | Threaded
Open this post in threaded view
|

Re: Overriding the text styler

Juan Vuletich-4
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.

Cheers,
Juan Vuletich


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Overriding the text styler

Phil B
On Tue, 2015-06-23 at 10:18 -0300, Juan Vuletich wrote:

> 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.
>

I think class-based is perfect and it has been working as expected for
every scenario I've thought of so far.  I didn't mention the hybrid
OMeta/Smalltalk case as I viewed that as being an issue for OMeta (or
whatever other language one was implementing) to deal with as that's no
different than the case of having to compile a Smalltalk method in an
otherwise OMeta class which OMeta also has to deal with.  I've pushed
out a new update which includes an updated OMeta2Extensions which
supports the new approach as well as better handling Smalltalk methods.
It's not done yet: the first time it sees a Smalltalk method in an OMeta
class it won't be formatted correctly but that's a bug to be fixed on my
end.

> Cheers,
> Juan Vuletich
>



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org