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

@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.

@Jacopo-Remondina , I am still not sure what you want for FOLDING and what you want for KEYWORD and what you want for DELIMITER and what you don’t want detected at all. But at this point, I’m guessing that what you want is too complicated for the simplistic keyword/token matching used for UDL. For FOLDING, it’s designed to either match spaces-not-needed so the open/mid/closing all don’t require spaces, or to match spaces-required so the open/mid/closing all do require spaces; it is not meant to mix, so that the open doesn’t require spaces but the close does. The easiest workaround is what you already know: enumerate them all. I don’t think you’re going to find a better solution.

@KRadiants said: 1: False on both counts. Here is an example line <attribute id="Selectors" type="LSString" value="SelectSkills(ed664663-93b9-4070-a54b-3c7b19c0e7b4,3);SelectSpells(61f79a30-2cac-4a7a-b5fe-50c89d307dd6,2,0,BardCantrip,,,AlwaysPrepared);SelectSpells(dcb45167-86bd-4297-9b9d-c295be51af5b,4,0,BardSpells);SelectEquipment(aab8c5b5-eacf-4867-8e5f-bd4de3a9132e,1,BardInstrument);SelectAbilityBonus(b9149c8e-52c8-46e5-9cb6-fc39301c05fe,AbilityBonus,2,1)"/> There is a blank before, and sometimes there is something before and/or after it Otherwise, this is correct. OK, so in this example you want to end up with: <attribute id="Selectors" type="LSString" value="SelectSkills(ed664663-93b9-4070-a54b-3c7b19c0e7b4,3);SelectSpells(61f79a30-2cac-4a7a-b5fe-50c89d307dd6,BardCantrip,,,AlwaysPrepared);SelectSpells(dcb45167-86bd-4297-9b9d-c295be51af5b,BardSpells);SelectEquipment(aab8c5b5-eacf-4867-8e5f-bd4de3a9132e,1,BardInstrument);SelectAbilityBonus(b9149c8e-52c8-46e5-9cb6-fc39301c05fe,AbilityBonus,2,1)"/> ? If that’s correct, try the same expression I suggested before, except remove the ^ from the front: Find what: (SelectSpells\([\d\-abcdef]+),\d+,\d+ Replace with: $1

@donho Reported to both sites per your request to help keep the community safe.

@Afik-Gilboa said: both of them have the “run as administrator” unchecked. so any ideas why it keeps opening in admin mode? apparently everything running as administrator here, not sure why but it’s everything… I recognize the symptoms - you probably have turned off the Windows UAC completely somehow and at the same time the account, you are logged in, has the administrator rights (then everything launched will have the admin rights as default). Check your Registry for EnableLUA REG_DWORD 0x00000000 in: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] (click on Windows Start, start typing “Reg” there, click on the Registry Editor (System) app offered and navigate there to the hive path above) If there is that 0x00000000 (OFF), change it do 0x00000001 (ON) and restart your PC.

@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

“400k severly wounded ukrainian soldiers”, sorry.

@Safe-Tex Firstly, the question of Palestine is not the subject here. Secundly, you can’t know Alan Kilborn’s opinion about Israel, Palestine, and the conflict which opposes them. Lastly, the reliability of sources as Fox News or the Times of Israel don’t have any impact on the reliability of ruSSian sources, which are usually putin’s way to spread his bullsh*t deceitful propaganda (so yes, ruSSian site => lies).