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 20:27:00 GMT


ASF GitHub Bot logged work on TEXT-111:

                Author: ASF GitHub Bot
            Created on: 03/Mar/19 20:26
            Start Date: 03/Mar/19 20:26
    Worklog Time Spent: 10m 
      Work Description: CAPS50 commented on issue #104: TEXT-111
   Hey @kinow, I was playing along with this method and found a possible infinite loop issue,
and another combination where this fix is not enough.
   I have a fix for those 2 cases, can I commit to this branch still, or shall I make a new
pull request?
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: 206935)
    Time Spent: 50m  (was: 40m)

> 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
>            Assignee: Bruno P. Kinoshita
>            Priority: Major
>             Fix For: 1.7
>          Time Spent: 50m
>  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