Attached is a patch to fix the "Replace" button. It was always using the selection, even when there wasn't any, and "in selection" wasn't clicked. Due to the way "find next" works, this only affected certain searches, and only in regex mode. Reported here: https://sourceforge.net/p/notepad-plus/discussion/331753/thread/1bd87c0e/
Attachment didn't work
Patch can be applied with a command as follows:
c:\utils\patxch.exe -p 1 -i E:\path\to\patches\0001-BUG_FIXED-Replace-on-some-text-doesn-t-work-e.g.-r-n.patch
Obviously replacing the appropriate paths. patxch.exe is a renamed patch.exe from unxutils - http://unxutils.sourceforge.net/
Hi Dave,
Thank you for the patch.
It fixes indeed replacement bug of \r\n in RegExpr mode.
However, I found a find bug of \r\n in RegExpr mode.
Just enable "Extend mode" then count \r\n in file "0001-BUG_FIXED-Replace-on-some-text-doesn-t-work-e.g.-r-n.patch" you provided: 46 matches.
Now enable "Regular Expression mode" then count \r\n in the same file: 43 matches.
This bug makes result of "replace all" for "\r\n" incorrect.
I checked FindReplaceDlg::processRange() function, it seems correct to me. Could there be a glitch in Scintilla part regarding PCRE?
Don
I'll take a look. Certainly sounds like there's something else wrong
somewhere. I'll probably not get chance to look at it till the weekend
though.
Cheers,
Dave.
On 29 Nov 2012 00:07, "Don HO" donho@users.sf.net wrote:
There was a bug in the BoostRegexSearch.cpp - it shifted the search start forward if the search start was at the end of a line or in-between line end characters. I don't know why it was like this. Removing this check fixes it, and I can't see any side effects.
Hi Dave,
The bug is fixed by the last patch therefore the first patch is not apply.
The patch is merged and committed in Rev. 990
Thank you for the fix.
Don