The oldNumNewlines method on fwt::TextChange is documented as "will be lazily calculated (calcualted) :-)" if left null, but if you actually do that you get a NullPointerException from the java peer.

RichTextPeer.java has this line

te.replaceLineCount = tc.oldNumNewlines.intValue();

which bypasses the Fan getter in TextChange:

Int? oldNumNewlines
{
  get
  {
    if (*oldNumNewlines == null) *oldNumNewlines = oldText?.numNewlines
    return *oldNumNewlines
  }
}

So I guess peer code doesn't act right with property getters, when calling into fan from a peer.

Thanks for catching that! I pushed a fix.

Side note: Andy and I thinking about maybe rewriting RichText to be implemented purely in Fan so that it can run in the browser.

RichText has a couple of other problems right now. The biggest weakness (for me) now is lack of pixel precision handling. It is also a bit hard to get font/character metric information which makes rich text pane scrolling and overlay graphics rather hard thing to get properly.

Though, I'd like to add, the underlying SWT component is the source of most problems. I've digged into Eclipse code and found out it resolves these issues manually - by creating a virtual screen, drawing elements and double buffering the result.

Pure Fan RichText code with pixel precision and overlaying support would be awesome!