Dear Jurgen: To follow up this conversation, after giving it some more thought, I think this change would be problematic - but for a different reason. The segments in UndoableChange are only available in a model that supports undo. If the model does not support undo/redo functionality, we don't have the UndoableChange and related segments, and I don't want to generate them.
Assuming that you absolutely cannot support your requirements with the existing APIs, and there is no reasonable workaround, the only possibility I see is to remove the final keyword from StyledTextModel applyStyle() and replace() methods. The at least you can intercept these calls and do the required processing there. I still not sure what the use case is for that though - don't you want to always process the updated document? What is your use case? Thanks, -andy From: Jurgen Doll <[email protected]> Date: Tuesday, November 4, 2025 at 01:40 To: Andy Goryachev <[email protected]> Cc: openjfx-dev <[email protected]> Subject: Re: [External] : Re: RichTextArea Feedback Hi Andy > This might get complicated - while that might work for an in-memory > model, it will be very complicated in the case of a large virtualized model. I don't see how it's complicated, and I don't think the model matters. As far as I can see the changes required are quite straightforward. Here's a brief outline: In StyledTextModel, in both the applyStyle:766 and replace(...,StyledInput):663 methods there's the line: UndoableChange ch = ... Then a little further down in both of these methods there's a fireStyleChangeEvent and fireChangeEvent line respectively which will now each get an extra parameter, something like: fire(Style)ChangeEvent(..., ch.getUndoSegments()); This extra parameter is a StyledSegment[] which is then passed on to ContentChange where it's made available via something like: getPreviousSegments() That's it :-) If I've missed the complicated part please let me know. Thanks, regards Jurgen On Nov 3 2025, at 8:59 pm, Andy Goryachev <[email protected]> wrote: > Right, sorry, missed that one. > > This might get complicated - while that might work for an in-memory > model, it will be very complicated in the case of a large virtualized model. > > An alternative might be to remove 'final' from replace(StyleResolver > resolver, TextPos start, TextPos end, StyledInput input), or to allow > a callback before the actual changes are made. > > I am not sure about the use case for this though. If you simply want > to do a syntax or spelling check highlighter, you might need to keep a > separate data structure that allows one to do, for example, a partial > update, or to get the plain text from the model, or something else entirely. > > -andy > > > From: Jurgen Doll <[email protected]> > Date: Monday, November 3, 2025 at 00:36 > To: Andy Goryachev <[email protected]> > Subject: [External] : Re: RichTextArea Feedback > > Hi Andy > >> Did I miss anything? Please let me know. #2 > > Also, the RFE regarding ContentChange: > This is a request to enhance ContentChange with an additional method: > getPreviousSegments() > > Currently ContentChange reports only where something has changed. > Using this one can determine the current state of the document, however > determining what has actually changed is impossible. So having this > extra information available would be helpful. > > I think this can easily be done in StyledTextModel where the previous > segments can be obtained by extracting them from the freshly created > UndoableChange object when calling fire?ChangeEvent(...) > > Thanks, regards > Jurgen
