Dear Pavel: Since the CodeArea is designed to support large models, adding the kind of values you ask to every update might be prohibitively expensive and/or impossible, given the dependency on the line endings format.
A solution is possible however - one can extend CodeTextModel to implement obtaining the character offset from a TextPos. Such a model may limit its content to in-memory and may also provide a property to encode the line ending policy, or even encode the line endings in the content. We could, in theory, provide such a model as a part of CodeArea package, something that I am still considering. -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of PavelTurk <pavelturk2...@gmail.com> Date: Wednesday, May 28, 2025 at 03:10 To: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> Subject: Re: CodeArea: request to raise priority of JDK-8357405 (text length metrics for ContentChange) Andy, thank you for your reply. When making changes, I think we have THREE key parameters: 1. startByte – this is the offset in the file where the change begins. If the document is very large, this value might require a long, although that would be one case in a billion. 2. removedLength – the length of the removed chunk of text starting from startByte. I think this will always fit in an int, but it could be a long as well. At the same time String#length() -> int. 3. insertedLength – the length of the inserted text starting at startByte. Again, I believe int should suffice, but long is also an option. Now, in JDK-8357405, only (2) and (3) are mentioned. So, the calculation of startByte is left for the future or for the user to handle. The reason for this is that the user can compute startByte themselves, but they cannot efficiently determine removedLength and insertedLength (at least I don’t know how). At the same time, I believe that during the change processing, the library itself can quite easily calculate these values and include them in the ContentChange. For example, when a portion of text is selected and replaced with something else, the library knows: a) the length of the selected text, and b) the length of the inserted text. If I’m wrong and the user can efficiently calculate removedLength and insertedLength using a custom model, could you explain how to do that? Because without this data, my work with JFX CodeArea is completely blocked. At the same time, wouldn’t it be better to support these values out of the box? Many code analysis libraries rely on them, and CodeArea is intended to be integrated with exactly those kinds of libraries. Best regards, Pavel On 5/27/25 20:51, Andy Goryachev wrote: Dear Pavel: This is not a trivial request. Currently, there is not easy way to control (override) the behavior of the CodeModel with respect to line endings. Line endings are not stored in the model, but they are emitted when saving/copying. Perhaps we ought to add a dedicated property to the model (line endings: CR/LF/CRLF/PLATFORM?) which would allow the application to specify the behavior and allow the model to perform the offset calculations. The other issue is that the CodeArea supports large models (CodeTextModel with a custom BasicTextModel.Content). Computing offsets in a large model not only may take a long time, but also produce result that does not fit into 31 bits. Which means, for all intents and purposes, this functionality should be implemented by a custom model. What do you think? Cheers, -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org><mailto:openjfx-dev-r...@openjdk.org> on behalf of PavelTurk <pavelturk2...@gmail.com><mailto:pavelturk2...@gmail.com> Date: Thursday, May 22, 2025 at 05:29 To: openjfx-dev@openjdk.org<mailto:openjfx-dev@openjdk.org> <openjfx-dev@openjdk.org><mailto:openjfx-dev@openjdk.org> Subject: CodeArea: request to raise priority of JDK-8357405 (text length metrics for ContentChange) I'd like to kindly ask for consideration in raising the priority of JDK-8357405 about adding text length metrics to ContentChange for removed/inserted text for CodeArea. The reason for this request is that accurate and reliable information about text changes is essential when integrating CodeArea with code processing libraries. Currently, CodeArea does not provide such information. As a result, CodeArea can only be reliably used in read-only mode at the moment — which severely limits its applicability in real-world applications. Best regards, Pavel
