<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Andy, thank you for your reply.<br>
<br>
When making changes, I think we have THREE key parameters:<br>
<br>
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.<br>
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.<br>
3. insertedLength – the length of the inserted text starting at
startByte. Again, I believe int should suffice, but long is also an
option.<br>
<br>
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).<br>
<br>
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:<br>
a) the length of the selected text, and<br>
b) the length of the inserted text.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Best regards, Pavel<br>
<br>
<div class="moz-cite-prefix">On 5/27/25 20:51, Andy Goryachev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CY8PR10MB72656DE7D085707CE16310B4E564A@CY8PR10MB7265.namprd10.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator"
content="Microsoft Word 15 (filtered medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}@font-face
{font-family:"Iosevka Fixed SS16";
panose-1:2 0 5 9 3 0 0 0 0 4;}@font-face
{font-family:"Times New Roman \(Body CS\)";
panose-1:2 11 6 4 2 2 2 2 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Aptos",sans-serif;}span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Iosevka Fixed SS16";
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}div.WordSection1
{page:WordSection1;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Dear
Pavel:<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">What
do you think?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">-andy<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div>
<div
style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span
style="font-size:12.0pt;color:black">From:
</span></b><span
style="font-size:12.0pt;color:black">openjfx-dev
<a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev-retn@openjdk.org"><openjfx-dev-retn@openjdk.org></a> on behalf of
PavelTurk <a class="moz-txt-link-rfc2396E" href="mailto:pavelturk2000@gmail.com"><pavelturk2000@gmail.com></a><br>
<b>Date: </b>Thursday, May 22, 2025 at 05:29<br>
<b>To: </b><a class="moz-txt-link-abbreviated" href="mailto:openjfx-dev@openjdk.org">openjfx-dev@openjdk.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev@openjdk.org"><openjfx-dev@openjdk.org></a><br>
<b>Subject: </b>CodeArea: request to raise priority
of JDK-8357405 (text length metrics for
ContentChange)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">I'd
like to kindly ask for consideration in raising the
priority of JDK-8357405 about adding text length<br>
metrics to ContentChange for removed/inserted text
for CodeArea.<br>
<br>
The reason for this request is that accurate and
reliable information about text changes is essential<br>
when integrating CodeArea with code processing
libraries. Currently, CodeArea does not provide<br>
such information.<br>
<br>
As a result, CodeArea can only be reliably used in
read-only mode at the moment — which severely<br>
limits its applicability in real-world applications.<br>
<br>
Best regards, Pavel<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>