I've noticed a problem with the editor highlighting for the caret row. In the following case, the highlighting doesn't
cover the whole line, but only the end of line, no matter how much text is added:

1. write some text, on one or multiple lines
2. select all text (ctrl+a)
3. delete the text (delete)
4. write some chars (without newline)
5. you'll notice that the chars don't have the caret-row background and that the caret row is visible, but starting from
the end of the text (till the end of line / end of the UI).

See attached screenshot made on OSX, I've seen it on Windows too.

After lots of debugging I've reduced the issue to the CompoundHighlightsContainer caching engine. If I disable caching
altogether the problem doesn't show up anymore, with a big penalty hit as the highlight layers are always queried.

The problem on the caching engine are actually the cacheLowestPos and cacheHighestPos variables because they are not
actually in sync with the cache (OffsetsBag). The OffsetsBug, ie. cache, adds a listener on the document for
insert/remove which notifies cache.marks.default{Insert|Remove}Update which in turn changes the mark's offset. *But*
this does not notify in any way the cache{Lowest|Highest}Pos vars which are bound to get out of sync.

So, on caret rows case, the marks become something like [0 - row color, 1 -null] with cacheLowestPos=0
cacheHighestPos=MAXINT. On each new insert marks.defaultInsertUpdate changes the marks to [document.length - row color,
document.length +1 - null] basically always moving the caret row highlights away from the new chars.

As cache{Lowest|Highest}Pos vars never change, the cache isn't refreshed and
CompoundHighlightsContainer.getHighlights(int,int) always return the broken interval (starting with document.length).

My fix involves using the rawOffset for the cache{Lowest|Highest}Pos vars and converting to normal document offset
during getHighlights(int,int). This way it seems that the OffsetsBag doesn't get out of sync. Of course, we also need
access to OffsetsBag.mark.{raw2Offset|offset2raw} methods. I'll also attach my change classes. These are by no means a
proper patch as I introduce new public methods and that's probably bad. Maybe you'll find another solution, this is what
I'm using right now.

Screnshot made on:
Product Version: NetBeans IDE 6.1 (Build 200804211638)
Java: 1.5.0_13; Java HotSpot(TM) Client VM 1.5.0_13-119
System: Mac OS X version 10.5.3 running on i386; MacRoman; en_US (nb)

Problem also visible on
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13-120)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_05-b13-52, mixed mode)