[
https://issues.apache.org/jira/browse/TEXT-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763382#comment-17763382
]
Michael Karnerfors edited comment on TEXT-231 at 9/9/23 10:34 PM:
------------------------------------------------------------------
The patch re-works WordUtils.wrap, in the following way...
* The main loop is completely rewritten, aiming to increase legibility of the
code
* The wrap method now respects pre-existing newline strings
* An inconsistency in how zero-length "wrapOn" patterns are treated has been
addressed (or, to be precise: the old code had a problem with this, the new
algorithm simply does not).
* Test cases for the wrap method are made parametrised and named
Note that this does break compatibility with some of the earlier test cases.
This is because zero length wrapOn pattern matches resulted in some odd
behaviour where characters that were _not_ part of the match were either
deleted or kept.
In the reworked version, only the portion of wrapOn that actually _matched_ is
eligible for removal on wrap.
Symptoms of this odd behaviour can be seen when using the old wrap function
with the new tests in the patch. In one case, the wrap function even fails with
a Out Of Bounds exception.
was (Author: michaelkarnerfors):
The patch re-works WordUtils.wrap, in the following way...
* The main loop is completely rewritten, aiming to increase legibility of the
code
* The wrap method now respects pre-existing newline strings
* An inconsistency in how zero-length "wrapOn" patterns are treated has been
addressed (or, to be precise: the old code had a problem with this, the new
algorithm simply does not).
* Test cases for the wrap method are made parametrised and named
Note that this does break compatibility with some of the earlier test cases.
This is because zero length wrapOn pattern matches resulted in some odd
behaviour where characters that were _not_ part of the match were either
deleted or kept.
In the reworked version, only the portion of wrapOn that actually _matched_ is
eligible for removal on wrap.
Symptoms of this odd behaviour can be seen when using the old wrap function
with the new tests in the patch. In one case, the wrap function even fails with
a Out Of Bounds exception.
> WordUtils.wrap should react to prexisting "new line string" as a wrap
> ---------------------------------------------------------------------
>
> Key: TEXT-231
> URL: https://issues.apache.org/jira/browse/TEXT-231
> Project: Commons Text
> Issue Type: Improvement
> Affects Versions: 1.10.0
> Reporter: Michael Karnerfors
> Priority: Minor
> Attachments: TEXT-231-wrap-on-newline-string.patch
>
>
> WordUtils.wrap ignores pre-existing occurrences of the "new line string" and
> counts them as part of a line, instead of as a wrap.
> Example:
> {code:java}
> public static final String LINE_SEPARATOR = "\n";
> void wrap() {
> String line = "Alpha"+ LINE_SEPARATOR + "Bravo Charlie Delta Echo
> Foxtrot";
> System.out.println(WordUtils.wrap(line, 13));
> } {code}
> The default new line string is just newline ("\n"). So in this case I would
> expect this to output...
> {noformat}
> Alpha
> Bravo Charlie
> Delta Echo
> Foxtrot
> {noformat}
> However, since WordUtils.wrap does not consider the pre-existing newline
> after "Alpha" as one of its own wraps, I instead get...
> {noformat}
> Alpha
> Bravo
> Charlie Delta
> Echo Foxtrot
> {noformat}
> There is a work-around, but it is not as elegant...
> {code:java}
> String wrappedLine =
> Arrays
> .stream(
> line.split(LINE_SEPARATOR)
> )
> .map(
> subLine -> WordUtils.wrap(subLine, 13)
> )
> .collect(
> Collectors.joining(LINE_SEPARATOR)
> );
> System.out.println(wrappedLine);
> {code}
> Hence, I suggest that WordUtils.wrap should consider matches of "newLineStr"
> as a wrap, and any directly following text as the beginning of the next line.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
