Option to not follow the caret on edit

[Arhowk]

There are two things I've noticed that differs this from a console (which is what I'm trying to make it)

1. area.setWrapText(true) will wrap text like a document writer. There should be an option that doesn't send the entire new word to a new line but instead breaks the word up based on text area width

2. Appending text will force the scroll all the way down. There should be an option to make this only happen if the scroll is equal to 1 beforehand.

[TomasMikula]

Hi Jake,

1. area.setWrapText(true) will wrap text like a document writer. There should be an option that doesn't send the entire new word to a new line but instead breaks the word up based on text area width

To support this, I would need TextFlow to support this first, since paragraphs are implemented as TextFlows.

2. Appending text will force the scroll all the way down. There should be an option to make this only happen if the scroll is equal to 1 beforehand.

Any edit to the text, including append, changes the caret position to the location where the edit occured and scrolls the viewport to make the caret visible. This makes sense for interactive editing—when you type something, you want it to be brought into the viewport. Implementing what you ask for is possible, but I would like to know more about your use case.

[ghost]

Would it work if you stored the initial insert position before inserting
new text, then then set the caret position back to the original position
after insertion?
On Dec 21, 2014 7:11 PM, "Jake" notifications@github.com wrote:

There are two things I've noticed that differs this from a console (which
is what I'm trying to make it)

1. area.setWrapText(true) will wrap text like a document writer. There
   should be an option that doesn't send the entire new word to a new line but
   instead breaks the word up based on text area width

2. Appending text will force the scroll all the way down. There should be
   an option to make this only happen if the scroll is equal to 1 beforehand.

—
Reply to this email directly or view it on GitHub
#102.

[TomasMikula]

I suppose that in @Arhowk's case, the original caret position is at the end of the document and the user has scrolled up, so the caret is out of the viewport. Restoring the original position after append would still scroll to the beginning of the appended text, while @Arhowk would like the viewport to stay stationary.

[Arhowk]

but I would like to know more about your use case.

I'm currently using a InlineCssTextArea to mimic a console. I ended up having to use this because I wanted to color coordinate the different text messages that were going in and out of the area. Some console lines (e.g hex dumps) are much larger than a line in the window so it drops to the next line and looks unprofessional.

[TomasMikula]

As I mentioned, the text wrapping feature is dependent on support for this in TextFlow, so JavaFX issue tracker is a better place to ask for this.

I was interested in your use case for locking the scroll position.

Btw, you probably don't want your console output to be editable. Without the editing capabilities, there is little additional value RichTextFX can offer you compared to just a ListView of TextFlows. About the only advantage I can think of is that RichTextFX supports text selection.

[TomasMikula]

As of #378, caret is not followed on an edit via the API.