-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--multiline
with --replace
causes duplicate output
#2095
Comments
Without the rg --multiline --only-matching '(?ms:^(?P<indent>\s*)a=(?P<value>[(].*?[)]|[^\n]*)$)' ./test.bash
rg --multiline --only-matching '(?ms:^(?P<indent>\s*)a=(?P<value>[(].*?[)]|(?-ms:.*))$)' ./test.bash
rg --multiline --only-matching '(?m:^(?P<indent>\s*)a=(?P<value>[(](?s:.*?)[)]|.*)$)' ./test.bash output:
|
--multiline
is causing duplicate output--multiline
with --replace
causes duplicate output
For the meantime, |
Yup, looks like a bug to me. Thanks for the report! |
I ran into this problem when working on a unified diff printer. It seems the replacement bytes retain the remainder of the subject buffer instead of only until the match end. I tried to fix it and it worked, but I'm not sure if my fix is a proper one. |
This furthers our kludge of dealing with PCRE2's look-around in the printer. Because of our bad abstraction boundaries, we added a kludge to deal with PCRE2 look-around by extending the bytes we search by a fixed amount to hopefully permit any look-around to operate. But because of that kludge, we wind up over extending ourselves in some cases and dragging along those extra bytes. We had fixed this for simple searching by simply rejecting any matches past the end point. But we didn't do the same for replacements. So this commit extends our kludge to replacements. Thanks to @sonohgong for diagnosing the problem and proposing a fix. I mostly went with their solution, but adding the new replacement routine as an internal helper rather than a new APIn in the 'grep-matcher' crate. Fixes #2095, Fixes #2208
This furthers our kludge of dealing with PCRE2's look-around in the printer. Because of our bad abstraction boundaries, we added a kludge to deal with PCRE2 look-around by extending the bytes we search by a fixed amount to hopefully permit any look-around to operate. But because of that kludge, we wind up over extending ourselves in some cases and dragging along those extra bytes. We had fixed this for simple searching by simply rejecting any matches past the end point. But we didn't do the same for replacements. So this commit extends our kludge to replacements. Thanks to @sonohgong for diagnosing the problem and proposing a fix. I mostly went with their solution, but adding the new replacement routine as an internal helper rather than a new APIn in the 'grep-matcher' crate. Fixes #2095, Fixes #2208
What version of ripgrep are you using?
How did you install ripgrep?
cargo
What operating system are you using ripgrep on?
Describe your bug.
outputs:
Instead of:
What are the steps to reproduce the behavior?
see above
What is the actual behavior?
see above
What is the expected behavior?
see above
What do you think ripgrep should have done?
It would be good if the
--multiline
handling could be disabled, in favour of the rust regex localised flag applied(?ms:
The text was updated successfully, but these errors were encountered: