RichTextArea undo style ContentChange

[Andy Goryachev]

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/20251030/c4faa82d/attachment-0001.htm>