[jira] [Comment Edited] (TEXT-111) WordUtils.wrap must calculate offset increment from wrapOn pattern length

["Pascal Schumacher (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TEXT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16325393#comment-16325393 ] 

Pascal Schumacher edited comment on TEXT-111 at 1/14/18 12:32 AM:
------------------------------------------------------------------

Thanks for reporting this!

I gave the suggested fix a try, but it causes other tests to fail.

A pull request/patch would be greatly appreciated.


was (Author: pascalschumacher):
Thanks for reporting this.

I gave the suggested fix a try, but it causes other tests to fail.

A pull request/patch would be greatly appreciated.

> WordUtils.wrap must calculate offset increment from wrapOn pattern length
> -------------------------------------------------------------------------
>
>                 Key: TEXT-111
>                 URL: https://issues.apache.org/jira/browse/TEXT-111
>             Project: Commons Text
>          Issue Type: Bug
>    Affects Versions: 1.2
>            Reporter: Michael Keppler
>
> WordUtils.wrap(...) allows to specify the "wrapOn" regular expression to be used as breakable characters. If this pattern is a zero width assertion or is longer than 1 charachter, then the output is wrong because the wrapping algorithm always skips one character (assuming the line break character has a width of 1).
> Example failing test:
> {code:java}
> assertThat(WordUtils.wrap("abcdef", 2, "\n", false, "(?=d)")).isEqualTo("abc\ndef");
> // produces "abc\nef" instead
> {code}
> Fix would be to change the 2 occurences of
> {code:java}
> offset = spaceToWrapAt + 1;
> {code}
> to
> {code:java}
> offset = spaceToWrapAt + matcher.end() - matcher.start();
> {code}
> thereby not advancing 1 character each time, but as many characters as were just matched.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)