On Fri, 8 Apr 2022 12:17:37 GMT, Tejesh R <d...@openjdk.java.net> wrote:
>> getText function returned extra endOfLine when appended. The reason was in
>> `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)`
>> method, where translation happens from buffer to Out(Writer Object) if
>> endOfLine is other than '\n' ( which is '\r\n' in windows). In order to
>> write each line till End of line, the string till '\n' is written including
>> '\r' and again endOfLine is written which results in extra Carriage Return.
>> To solve this issue, a Condition is added which checks if previous character
>> to '\n' is '\r', if true then whole string except Carriage Return ('\r') is
>> written, else whole string till before '\n' is written.
>
> Tejesh R has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Updated based on Review Comments
Not 100% certain on this but "not an issue" sounds safest to me.
Doing nothing is the only way to be sure you didn't introduce a regression.
I'd expect folks who were doing this from code learned .. but what happens if a
user pastes
a few lines of text from windows Notepad - and it contains \r\n ?
You can't stop users doing that and they will be surprised.
If that is happening I'd give serious consideration to doing the translation of
\r\n -> \n not just
on reading the initial text but in all mutations of the text.
at the very least if we already set DefaultEditorKit.EndOfLineStringProperty
we'd want to ..
But would such mutations alone also trigger setting
DefaultEditorKit.EndOfLineStringProperty ?
-------------
PR: https://git.openjdk.java.net/jdk/pull/8122
