commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Work logged] (TEXT-111) WordUtils.wrap must calculate offset increment from wrapOn pattern length
Date Sun, 03 Mar 2019 08:05:00 GMT


ASF GitHub Bot logged work on TEXT-111:

                Author: ASF GitHub Bot
            Created on: 03/Mar/19 08:04
            Start Date: 03/Mar/19 08:04
    Worklog Time Spent: 10m 
      Work Description: kinow commented on issue #104: TEXT-111
   Change looks good to me! No backward compatibility issues, Travis-CI is happy with the
code changed, a test was included. And it looks like it fixes the bug. @PascalSchumacher would
you like to have a look too before it gets merged? I saw that you commented in the issue some
time ago. Cheers
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

Issue Time Tracking

            Worklog Id:     (was: 206865)
            Time Spent: 10m
    Remaining Estimate: 0h

> WordUtils.wrap must calculate offset increment from wrapOn pattern length
> -------------------------------------------------------------------------
>                 Key: TEXT-111
>                 URL:
>             Project: Commons Text
>          Issue Type: Bug
>    Affects Versions: 1.2
>            Reporter: Michael Keppler
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
> 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

View raw message