@PeterJones said: PeterJones said: I assume the Search++ syntax would be the same Per the Search++ announcement, it can do the numeric calculations that were first developed for Columns++. I should update the FAQ soon… I recommend waiting on that update. Search++ is not “production ready” yet. People shouldn’t be using it at present unless they want to be beta testers. Once I reach a 1.0 release I’ll make a serious effort to avoid changing things that people would expect to stay the same, but right now, anything could be changed at any time. Numeric expressions in Search++ do not have quite all the features of numeric expressions in Columns++; in particular, the history options (using the values captured or computed in a previous match) aren’t supported in Search++, and the exprtk return statement isn’t supported. However, I think all the features directly cited in the Math FAQ are included. The reg(1) syntax still works, but in Search++ you can use $1 as well. However, a quirk is that since Search++ doesn’t have the persistent Decimal separator is comma option of Columns++, it’s necessary to use regc(1) or $$1 for European-style numbers with periods and/or commas. Finally, Columns++ can only work on the active document. Search++ has a Find in Files option, but Replace in Files has not yet been implemented. So if your guess was correct and @neculai-i.-fantanaru wants a regular expression because it must be applied to many files at once, @thomas-knoefel’s MultiReplace is the best choice among presently-existing options. Oh, and MultiReplace has recently added an option to use exprtk formulas as an alternative to its Lua syntax.

@guy038 Hello @guy038, Thanks for this thorough test, and no, you didn’t do anything wrong. Your investigation uncovered two separate behaviors in the code: Binary Files: MultiReplace “Find in Files” currently skips binary files, while native N++ searches every file it lists. That accounts for most of the gap in your USB drive numbers. I’ll look at how to make this configurable and more transparent. UTF-16 Bug: There is indeed a bug in how “Find in Files” handles UTF-16 encodings compared to “Find in Docs” and “Replace in Files”. This most likely explains the missing files in your smaller Test folder too. Since the forum isn’t ideal for sharing files and tracking bug fixes, I have opened a GitHub issue for this here: https://github.com/daddel80/notepadpp-multireplace/issues/133 I would gladly take you up on your offer to share the E:\Test folder contents so I can verify the fix against them. Could you please attach that folder as a zip or provide a link in the GitHub issue? Thanks again for your time and for helping to polish the next release candidate!

Hello, @coises, @thomas-knoefel and All, @Coises, you said : So I’m wondering, if you happen to remember, whether you tested in the order you listed, or whether you happened to test Search++ first? Well, since my previous tests were done in July 18, 2026, I don’t remenber exactly the way I used but I suppose that I first tested the native N++ search ! Thus, I decided to conduct a new series of tests. Of course, the results of the entire scan of my D: USB drive, are slightly different. Luckily, the number of matches and files containing the Fi string are identical between the Search++ search and the Notepad++ search IMPORTANT : I updated Search++ to the last 0.6.5 version, before all these tests So, this time, I first use the Search++ Find in Files dialog : I stop and re-start my W11 laptop I pluged my USB key I start N++ I ran an entire scan of my D: USB key for the Fi string, using the Search++ plugin => I got 27,081 matches in 841 files of 1,772, in 2m 10s I close N++ I unpluged my USB key I stop and re-start my W11 laptop I re-pluged my USB key I start N++ I ran an entire scan of my D: USB key for the Fi string, using the native Notepad++ search => I got 27,081 matches in 841 files of 1,772, in 1m 21s As you can see, no real difference between these tests and those of July 18 ! On the other hand, this time, the results obtained with the MultiReplace plugin are completely different. After a complete re-start of my machine I ran an entire scan of my D: USB key for the Fi string, using the MultiReplace plugin => I got 18,767 hits in 726 files in 1m 05s. Most of non text files are not scanned at all ?! I don’t understand these huge differences ? I first suspected that I allowed this option in MultiReplace settings : File Search : Skip files larger than but this option is not set ! Thus, right after this post, I’m going to post to @thomas-knoefel for possible information ! Remark that this present post is saved on a different USB drive to avoid future changes regarding the number of matches of the Fi string ! To end, @coises, you said : In any case, after weeks of running in circles, I think I will soon give up the fight to optimize performance and see what else needs work. I totally agree with this wise statement !! Best Regards, guy038

@guy038 I can creat a Python script :) but the beauty and art was finding a solution just with regex.