decouple RichTextFX from string, use CharSequence

[Groostav]

(CC: @VinnieH)

As a developer writing a tool for which I cannot gaurentee that the text rendered will be a reasonable size, I would like RichTextFX to keep the minimal content in memory necessary, streaming text off the disk rather than loading it into strings, so that I can sleep easy.

Basically I'd like to decouple RichTextFX from Strings in favor of CharSequences so that I might use @fge's largetext library instead of a flat string. This would make your library fairly agnostic to how it gets the data and give me a shim for lazyness.

Note that CharSequence specifies the two most critical parts of String: subSequence and charAt, in addition to fancy-new IntStreams for codePoints() and chars(), meaning there shouldn't be anything you can do with Strings you cant do with CharSequences. The one major gotcha is that CharSequence is not strict about how it implements equality, so you need to be careful when keeping lists or sets of them and calling contains().

Its also worth mentioning that LargeText's current subSequence() implementation does currently pull the specified subsequence into memory, so if the running code doesn't handle those carefully (possibly with SoftReferences in the case of paragraphs?) then the advantage will be nullified.

Sound reasonable? I could do it myself, but this eventing/reactive system is new to me so I'm likely to make some silly mistakes.

[TomasMikula]

There is some recent development towards not caring where the underlying document comes from and how it is represented: you can now implement your own EditableStyledDocument and be as lazy as you wish. There is a hard limit, though: even if only part of a paragraph would be visible, the content of the whole paragraph has to be in memory. This comes from paragraph being displayed as TextFlow, which needs all the content in memory. Other than that, RichTextFX already doesn't keep TextFlows for paragraphs that are out-of-view in memory. So implement your lazy EditableStyledDocument and you should be good to go.

[TomasMikula]

Closing this, since the path to have an on-disk document would be quite different than described, namely via implementing a custom EditableStyledDocument. Feel free to give it a try.

[Groostav]

Hey @TomasMikula so I we got some feedback from our customers basically demanding that we work with text files on the order of 100 MB. I'm willing to be that these files have regular newline characters, meaning the requirement that whole paragraphs be loaded should be a non issue.

Looking at the EditableStyledDocument I'm rather confused.

Firstly I'm confused because I'm using the StyleClassedTextArea in a non-editable manner. In that sense, the interface StyledDocument is looking much more up my alley, but it seems that the text area requires an editable document whether its going to edit it or not. Perhalps editable has a different meaning for you guys than it does for me? Perhalps I can simply implement EditableStyledDcoument with the replace methods simply set to throw for my purposes?

Outside of that, I'd need an implementation of a lazy Observable list for paragraphs, and then I'd need to re-implement Paragraph (and/or StyledText) to hit a cache or keep a soft-reference to its content.

That seems hard.

What I'd like to do is parameterize the StyledDocument implementations on a ParagraphFactory that would simply hit my cache. I would also need to have some life-cycle control over how long the substring instances live, so the ability to back a Paragram with a custom CharSequence or a Cached<SoftRef<String>> would do the trick too.

Any chance I can get that?

[JordanMartinez]

Firstly I'm confused because I'm using the StyleClassedTextArea in a non-editable manner. In that sense, the interface StyledDocument is looking much more up my alley, but it seems that the text area requires an editable document whether its going to edit it or not. Perhalps editable has a different meaning for you guys than it does for me? Perhalps I can simply implement EditableStyledDcoument with the replace methods simply set to throw for my purposes?

The area assumes that you'll edit the document in some way. Although it sounds like you disable the user's ability to edit it through the UI, it still allows the developer to programmatically modify it throughout the application's lifecycle. replace is the method through which all other edit calls are made, so if you modified that to throw some Exception, I'm not sure how you would be able to initialize the document. After the document is created, one still needs to use replace to actually add content to it.

As for your other questions, it might be better to let Tomas respond to that. However, he's been silent on this project for about the last month and a half (see #356), so I'm not sure when he'll respond.

Have you considered forking this project and modifying it according to your needs?