[Cuis] Overriding the text styler

[Phil (list)]

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