RichTextArea undo style ContentChange

[Jurgen Doll]

Hi Andy

Just to be clear, my main purpose was to report the undo bug. It occurs when either setStyle or applyStyle are invoked and then undo is called afterwards. The problem is that ContentChange.undo invokes model.replace(....) which is incorrect in this case, where as it should be model.applyStyle(....) because the former results in an event being fired where ContentChange.isEdit returns true when it should be false.
Also to be clear I have no problem with your current PR, it makes sense. I'm not advocating for stopping or changing it :-)
Here's a use case for styling: imagine an editor, like an IDE maybe, that has a search function that highlights all matching words. We'd like those highlights to remain in place even if undo/redo actions are called. That is the user doesn't expect the highlights to disappear on surrounding matches if undo is invoked on their last edit.
I think allowing styling to behave in this way is safe because it doesn't change the structure of the document, only it's appearance, so the structural state of the document is always consistant.
Thanks, regards
Jurgen

On Oct 30 2025, at 7:14 pm, Andy Goryachev <andy.goryachev at oracle.com> wrote:
> Jurgen:
>
> Thanks for the feedback! The main reason I've decided to remove this parameter is that selectively disabling / enabling undo functionality messes up the internal state.
>
> Perhaps, when the application edits/styles the document on its own, it should do it in steps - for example, I noticed that Apple Notes allows the user to undo the auto-format like bulleted list (I think MS Word does a similar thing). Also, there is currently no way to coalesce undo records (see https://bugs.openjdk.org/browse/JDK-8370447 ) and no API to allow the model to customize the process.
>
> I do want to understand your use case - can you explain it in more detail please? Give me an example of the expected behavior?
>
> Thanks!
> -andy
>
> From: openjfx-discuss <openjfx-discuss-retn at openjdk.org> on behalf of Jurgen Doll <jurgen at ivoryemr.co.za>
> Date: Thursday, October 30, 2025 at 09:35
> To: openjfx-discuss at openjdk.org <openjfx-discuss at openjdk.org>
> Subject: RichTextArea undo style ContentChange
>
> Hi Andy
>
> In view of your current "remove allowUndo parameter" PR, I took another look at why I requested that applyStyle and setStyle also have that parameter. Part of the reason, I have now discovered, is due to a bug in the way that undo is processed.
>
> Basically when undoing a STYLE ONLY change an event is fired where ContentChange.isEdit returns true when it should be false. To fix, I think that the UndoableChange.create() method needs a styleOnly flag (or maybe another method needs to be added for style only changes). Then when the UndoableChange.undo method is called it can invoke model.applyStyle() with appropriate values instead of model.replace() which will then trigger the correct event.
>
> Note that even with this fixed though, it might still be desirable to be able to add/remove styling with an undo parameter. The use case I have is that only user styling actions are on the undo stack but programmatic changes for spellchecking or other markup are skipped if desired. The effect this has is that when the user undoes something it's directly related to what they have just done and not what the program has done.
>
> Thanks, regards
> Jurgen
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-discuss/attachments/20251031/4cff057c/attachment.htm>