"Interval Highlighting" in latest RBCodeHighlighter

> Karsten Kusche wrote:
>> Hi Travis,
>> [..]
>>  I fully agree
>> that this color should be changeable in the settings, as well as it
>> should be able to simply turn it off.
>
> done
>
>> I guess a bright yellow would fit better on a mac.
>
> done (default value)
>
>>> I've also seen cases where it highlights wrong for 's. If you put
>>> your cursor to the left of the first ' mark, it will highlight all
>>> the way to the front of the method.
>
> fixed
>
> Published as 1.55 in the open repository
>
> Cheers, Holger
>
>

> On Oct 12, 2006, at 13:12, Holger Kleinsorgen wrote:
>
>> Travis Griggs wrote:
>>
>>> The string
>>> 'I can''t seem to make this work right'
>>> won't do the right thing. Or writing code with a statement like:
>>> blah ifTrue: [aStream nextPut: $[].
>>
>> This can be hardly fixed unless the highlighing mechanism is
>> fundamentally changed. Currently it is not integrated into the
>> highlighting scanner/parser and therefore has to guess what a
>> Character within the sourcecode means. And as you point out, it makes
>> wrong assumptions from time to time.
>
> Yes, I thought about this some. I've proven to myself that I can use
> the highlighting scanner parser to "backColor" enclosures. And it does
> it "correctly". But if you're doing backlighting, this runs into
> conflict with the highlighting mechanism of selection in the editor.
> To do it "right", one could "augment" the highlighting scanner/parser
> with info about the current insertion point. Then it can do "more"
> when the insertion point crosses an interesting node. Or... one could
> simply use the parser to "mark" the matching left and right parens.
> Basically emphasize each left token with a #left -> increasingCounter
> emphasis, and the right with the appropriate #right ->
> currentCounterBeforeIDecreaseIt. Then the text controller can simply
> check the emphasis of it's current text at the insertion point and go
> nuts with it.
>
>>
>>> Karsten and I have exchanged some emails in the background. I like  
>>> the idea of drawing the coder's attention to the enclosure.  
>>> Fundamentally, I think any form of "highlighting" is not the way to  
>>> do it. Textual highlighting has too many long and established  
>>> meanings already. That said, I realize the onus is on me, the  
>>> detractor, to volunteer something better.
>>
>> There probably won't be an ultimate solution. For instance, I don't
>> like the way Emacs highlights enclosures (flashing the other end of
>> the enclosure). Actually, I don't like flashing at all.
>>
>> The following visualisations come to my mind:
>> - highlighting (like it is done now)
>> - displaying the enclosure with a different text style
>> - highlighting the other end of the enclosure
>> - displaying the other end of the enclosure with a different text
>> style (e.g. red / bold)
>> - everything mentioned above with flasing, or static.
>> - automatically refactoring enclosures that are too complicated to
>> comprehend at a glance, thereby eliminating the necessity to
>> highlight the enclosure ;)
>
> There probably isn't an ultimate solution. I actually played with a
> number of emphases. Some alone, some in isolation. Large/small.
> Underline. Overline. Strikethrough. Super/Sub script. Various
> combinations. There are all kinds of issues with many of them.
> Ultimately, I hate them all. The real intent (in my mind) is given a
> an enclosure token, draw the users attention to the span of the
> enclosure and the other token. The "stuff" that's inside the enclosure
> is almost an afterthought. But any character emphasis draws make the
> "stuff" in between the focus, and the enclosing tokens are the
> afterthought. This probably isn't making any sense. :)
>
> Anyway, I tried something a little different. In fact, quite a bit. It
> may be stupid. But it's at least original. And shows the kind of stuff
> you can choose to do when you don't use native widgets. I don't think
> I've ever seen any sort of "enclosure" marking that looks like it.
> You'll have to load 1.56a to see it though. Curious about reactions. I
> kind of think it's cute/cool. I might just like it right now because
> it IS different. You can all hate it.  But you're gonna have to work
> hard to be more original. :)
>
> --
> Travis Griggs
> Objologist
> "It's [a spec] _the_ single worst way to write software, because it by
> definition means that the software was written to match theory, not
> reality" - Linus Torvalds
>
>

> Yes. Tweaking the parameters is kind of tricky. I was tired and wanted
> to publish. At one point, I had something nice for "short distances",
> but it got neglected as I tuned things for longer distances, both on
> the same line and multiline ones. But I'll see if I can't special case
> that to get it back. Did you change the color? I found red (or an
> orange close it) or darkCyan were both nice. I've been using it for
> the last hour or so, and it's grown on me. The implementation is
> actually a bit simpler than the highlighting approach. In addition to
> "short" enclosures, I'd like to do something different for the case
> where the right token is below the left one AND to the left of the
> left token.
>

> Travis Griggs wrote:
>> Anyway, I tried something a little different. In fact, quite a bit. It
>> may be stupid. But it's at least original. And shows the kind of stuff
>> you can choose to do when you don't use native widgets. I don't think
>> I've ever seen any sort of "enclosure" marking that looks like it.
>
> It's cute & original, but quite the opposite of what I want. I don't
> like eye-catching visualisations that distract me. IMHO it should be
> something that is so unobtrusive that it can be ignored in the normal
> case of simple enclosures.
> Maybe the enclosure highlighting should only performed in nested or very
> long enclosures.
>
> PS: Suddenly, some kind of Karaoke-like highlighting comes to my mind ;)
>
>