[vwnc] [RBCH] Update: Multiple Highlighters, Highlighting Styles, Spellchecking, etc....

This is hopefully my last message about this particular set of changes, but I felt I should post an FYI that I've merged the proposed changes to the RBCodeHighlighting trunk. The final version list is:

        TextHighlighting(7.7 - 12)
        HighlightingStyles(7.7 - 14)
        RBCodeHighlighting(7.7 - 3)
        HyperlinkHighlighting(7.7 - 10)
        Spellchecker2(15)
        SpellcheckHighlighting(7.7 - 18)

These versions are also queued up for this week's VW7.7 build. Those on vw-dev can watch for AR#56361: "Update RBCodeHighlighting (TextHighlighting, HighlightingStyles, SpellcheckHighlighting HyperlinkHighlighting)".

For those who missed previous discussion here's a brief recap of the changes:

Pretty much all aspects of highlighting activity can now be controlled via settings. There's a nice settings page for the highlighting styles with several predefined styles to pick from and you can mix and match 3 kinds of independent highlighters: code, spelling and hyperlinks.

The extracted highlighting controller functionality (i.e. the inner workings of the highlighters extracted from RBCH)  is now in a package called TextHighlighting. The highlighting style sheet support & corresponding settings tools are in HighlightingStyles. The rest are various specific highlighter packages, one of which is the RBCodeHighlighting. All of them should be arbitrarily loadable and un-loadable.

Another thing worth noting is that while the development was happening primarily in the context of VW7.7 builds, these new versions should run in 7.6 images as well, with the caveat that for HyperlinkHighlighting you'll need to remove the BrowserCommentTool>>text: method for proper function.

Thanks again for all the feedback,

Martin

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi all,

  I toyed around a bit and it seems there is a design flaw in  
DelegateHighlighter:


Consider for example adding a highlighter to the debugger which will  
highlight the current PC. The debugger client has no methods that  
expose the current PC so the highlighting is best implemented in the  
context of (i.e. on) the Debugger client - making it a perfect  
candidate to be a subclass of DelegateHighlighter. However  
DelegateHighlighter fixes the method names to be used on the debugger  
client so it is impossible to add one (because the RBCodeHighlighter  
already implements these methods on the debugger client). This is  
confusing because the whole idea of using pragmas to add highlighters  
is to enable such extensions.

I guess the method names to use for highlighting are better declared  
as a subclass responsibility on DelegateHighlighter.




For highlighters that can do without settings and activation logic (I  
guess the above example of highlighting the PC range counts) such a  
modified DelegateHighlighter is getting overly 'frameworky' to my  
taste, perhaps a specialized pragma for these cases is in order so all  
of the declarations can be stuffed into a single method.


Something along the lines of

highlightPC: aText

        < simpleHighlighterNamed: #PCRangeHighlighter >

        |range|
        "access local context:"
        range := service pcRange.
        "do the highlighting:"
        ...



R
-



On Feb 19, 2009, at 3:53 AM, [hidden email] wrote:

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout,

True, the method selectors are fixed, but the receiving object is not.  You could use a wrapper that redirects sending the #highlight:from: methods to the appropriate PC-range methods you want in the debugger client.  Adding a wrapper class might not be the best idea, but at least what you hypothesize is not impossible.

What we have here was a first attempt at an abstraction for delegation.  I admit I thought about using blocks or configurable aspects instead of fixed method names.  I only had the one case (code highlighting) to work from, and my imagination was a bit infertile in considering other uses.  As for the subclass responsibility notes, I do believe that the responsibility of the tool to implement #highlight:from: and #unhighlight:from: is in the class comment for DelegateHighlighter.  (Well, if it isn't, it was, as we've had a few hiccups with merging them.)

As for avoiding all that activation stuff, I don't think you can with the way things work.  Highlighters are added to the controller, which through a background process re-applies the highlighting.  Without the registration aspect, we really don't know what to apply.  I don't think pragmas are the answer, because then I would have to evaluate the pragma search each and every time I performed highlighting.  Perhaps I'm missing your intent?

Travis' suggestion (and I think his overall goal) to switch this to use the announcement capabilities would probably eliminate your concerns.  We didn't think we had the time to make those changes and get them to work properly.  On the other hand, I have a gut feeling that announcements might not work well in some case, but that remains to be tried and tested.

Cheers!
 
Tom Hawker
--------------------------
Senior Framework Developer
--------------------------
Home +1 (408) 274-4128
Office +1 (408) 576-6591
Mobile +1 (408) 835-3643
 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Reinout Heeck
Sent: Thursday, February 19, 2009 3:13 AM
To: VW NC
Subject: Re: [vwnc] [RBCH] Update: Multiple Highlighters, Highlighting Styles, Spellchecking, etc....

Hi all,

  I toyed around a bit and it seems there is a design flaw in  
DelegateHighlighter:


Consider for example adding a highlighter to the debugger which will  
highlight the current PC. The debugger client has no methods that  
expose the current PC so the highlighting is best implemented in the  
context of (i.e. on) the Debugger client - making it a perfect  
candidate to be a subclass of DelegateHighlighter. However  
DelegateHighlighter fixes the method names to be used on the debugger  
client so it is impossible to add one (because the RBCodeHighlighter  
already implements these methods on the debugger client). This is  
confusing because the whole idea of using pragmas to add highlighters  
is to enable such extensions.

I guess the method names to use for highlighting are better declared  
as a subclass responsibility on DelegateHighlighter.




For highlighters that can do without settings and activation logic (I  
guess the above example of highlighting the PC range counts) such a  
modified DelegateHighlighter is getting overly 'frameworky' to my  
taste, perhaps a specialized pragma for these cases is in order so all  
of the declarations can be stuffed into a single method.


Something along the lines of

highlightPC: aText

        < simpleHighlighterNamed: #PCRangeHighlighter >

        |range|
        "access local context:"
        range := service pcRange.
        "do the highlighting:"
        ...



R
-


IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not intended for you, please delete it immediately unread.  The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in doing so.  Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email.  Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Feb 19, 2009, at 8:37 AM, <[hidden email]> <[hidden email]
 > wrote:

> <snip>  I don't think pragmas are the answer, because then I would  
> have to evaluate the pragma search each and every time I performed  
> highlighting. <snip>

Is this because of performance concerns Tom?

There is a way to avoid this and have things go pretty efficiently. If  
you can look in VW7.7 builds (for the last month or two), you'll see  
how MethodDefinition manages to use pragmas to register candidate  
toolListIcons. Asking a MethodDefinition for a toolListIcon is  
something that gets done lots, just scrolling through a list hammers  
it. So doing a multi class method dictionary select for those methods  
that are tagged just so, is a recipe for a lot of extra work. Which we  
avoid doing.

The basic technique was "white papered" here:

http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Pragmatic_solution_to_Extensible_but_Efficient_Case-Like_Statements&entry=3403304603

> Travis' suggestion (and I think his overall goal) to switch this to  
> use the announcement capabilities would probably eliminate your  
> concerns.  We didn't think we had the time to make those changes and  
> get them to work properly.  On the other hand, I have a gut feeling  
> that announcements might not work well in some case, but that  
> remains to be tried and tested.

The above is correct. My goal is to merge things like ParagraphEditor  
and TextEditorController, not make more subclasses. :)

--
Travis Griggs
Objologist
"HTTP. It's like a bike pretending to be a bus, a bulldozer, and a cup  
of coffee at the same time." - Martin Kobetic


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Travis,

Yes, well, I'm home sick with my head stuffed full of gunk.  I usually use a caching approach that clears the cache on any update and reconstructs it in the accessor method.  I don't generate code or blocks because I don't often need to get that extra fraction of performance in-lining gives over sequence iteration.  It's just that something is nagging me that it won't work, or doesn't lend itself well, to this particular situation.

It's not that pragmas aren't the solution, it's where you have to put the smarts to cache the pragmas.  I probably misunderstood the intention, but it looked as if you were putting the pragmas either 1) in a generic class where you would have a hard time selecting which pragma to look at or (2) in a specific class which would have to introduce the pragma cache for itself.  I admit the latter is probably what you want, but then you have to duplicate that code for every new kind of thing you want to do.

Let me think about it when the synapses are actually functioning and not being short-circuited by the swamp between my ears.

Cheers!
 
Tom Hawker
--------------------------
Senior Framework Developer
--------------------------
Home +1 (408) 274-4128
Office +1 (408) 576-6591
Mobile +1 (408) 835-3643
 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Travis Griggs
Sent: Thursday, February 19, 2009 9:42 AM
To: VW NC
Subject: Re: [vwnc] [RBCH] Update: Multiple Highlighters, Highlighting Styles, Spellchecking, etc....


On Feb 19, 2009, at 8:37 AM, <[hidden email]> <[hidden email]
 > wrote:

> <snip>  I don't think pragmas are the answer, because then I would  
> have to evaluate the pragma search each and every time I performed  
> highlighting. <snip>

Is this because of performance concerns Tom?

There is a way to avoid this and have things go pretty efficiently. If  
you can look in VW7.7 builds (for the last month or two), you'll see  
how MethodDefinition manages to use pragmas to register candidate  
toolListIcons. Asking a MethodDefinition for a toolListIcon is  
something that gets done lots, just scrolling through a list hammers  
it. So doing a multi class method dictionary select for those methods  
that are tagged just so, is a recipe for a lot of extra work. Which we  
avoid doing.

The basic technique was "white papered" here:

http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Pragmatic_solution_to_Extensible_but_Efficient_Case-Like_Statements&entry=3403304603

> Travis' suggestion (and I think his overall goal) to switch this to  
> use the announcement capabilities would probably eliminate your  
> concerns.  We didn't think we had the time to make those changes and  
> get them to work properly.  On the other hand, I have a gut feeling  
> that announcements might not work well in some case, but that  
> remains to be tried and tested.

The above is correct. My goal is to merge things like ParagraphEditor  
and TextEditorController, not make more subclasses. :)

--
Travis Griggs
Objologist
"HTTP. It's like a bike pretending to be a bus, a bulldozer, and a cup  
of coffee at the same time." - Martin Kobetic

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not intended for you, please delete it immediately unread.  The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in doing so.  Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email.  Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc