https://bugs.documentfoundation.org/show_bug.cgi?id=153408

            Bug ID: 153408
           Summary: F&R's Replace All incorrectly replaces a character
                    after an anchor appeared after the first replacement
           Product: LibreOffice
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Writer
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected]

In a text document:

1. Type "aaaab cccccdeeeee" in a new paragraph;
2. Edit->Find and Replace (Ctrl+H);
3. Enable regular expressions;
4. Use this regex: "^a", replace with nothing, Replace All

==> expected result: "aaab cccccdeeeee" (one occurrence of "a" at the start of
the paragraph is removed).
    actual result: "b cccccdeeeee" (all the "a"s are removed from the
beginning, as if the search was restarted after each replacement).

5. Use this regex: "\bc", replace with nothing, Replace All

==> expected result: "b ccccdeeeee" (one occurrence of "c" at the start of a
word is removed).
    actual result: "b deeeee" (all the "c"s are removed from the beginning od
the word, as if the search was restarted after each replacement).

6. Use this regex: "e$", replace with nothing, Replace All

==> expected and actual result: "b deeee" (one occurrence of "e" at the end of
the paragraph is removed).

==========

The user-visible result of "replace all" must match the behavior of regex' "g"
flag: all matches are fund first, then each match gets replaced. This means,
that in the string "aaaab cccccdeeeee", the regex "^a" only matches one "a"
character in the beginning, and all the other "a" characters do not match in
this particular "Replace All" operation. This must also match the behavior of
"Find All" operation: i.e., all the same selected pieces found by "Find All"
must be replaced in Replace All, not more.

Note also anther internal inconsistency, where step 6 does not suffer from a
similar flaw, and only replaces one last character, not every character that
becomes the last after the previous replacement.

The expected behavior can be tested e.g. at https://regex101.com/r/6beT3Y/1

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to