@PeterJones said: If you’ve got steps that work for doing a local debug build, that would be helpful. > where cmake C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe > type .\build_gup.ps1 param ( [string]$Configuration = "Debug", [string]$Platform = "x64" ) if (-not $(Test-Path "${PSScriptRoot}\wingup\.git")) { git clone --single-branch https://github.com/notepad-plus-plus/wingup.git wingup } try { pushd "${PSScriptRoot}\wingup" $CmakeArchParam=$(if ("$Platform" -imatch "x86") {"Win32"} else {"$Platform"}) $LibPlatform=$(if ("$Platform" -imatch "Win32") {"x86"} else {"$Platform"}) cmake -S ".\curl" -B ".\curl\build\$LibPlatform" -A $CmakeArchParam ` -DBUILD_SHARED_LIBS=OFF ` -DCURL_STATIC_CRT=ON ` -DBUILD_CURL_EXE=OFF ` -DCURL_USE_SCHANNEL=ON ` -DCURL_USE_OPENSSL=OFF ` -DBUILD_TESTING=OFF ` -DUSE_LIBPSL=OFF ` -DCURL_USE_LIBPSL=OFF ` -DUSE_NGHTTP2=OFF ` -DUSE_LIBIDN2=OFF cmake --build ".\curl\build\$LibPlatform" --config $Configuration pushd vcproj msbuild GUP.sln /v:m /p:configuration=$Configuration /p:platform=$LibPlatform popd } catch { $_.InvocationInfo.PositionMessage; $_.Exception.Message } finally { popd } > powershell .\build_gup.ps1 Debug x86 # ...

@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 I can creat a Python script :) but the beauty and art was finding a solution just with regex.

@guy038 said: You can verify that, in the table, at that time, the Search++ and Multiplace plugins, unlike N++, did a Find in Files search on the saved files on disk and not on the N++ buffers possibly modified Yes, that is a condition I have not yet addressed, and it is good that you call it to my attention. I am more inclined to raise a warning box telling the user that some of the files to be searched are currently open in Notepad++, and the search results (and modifications, when I get Replace in Files done) will apply to the stored files, not to the edits in progress in Notepad++. The way these searches work would make it difficult (probably not impossible, but difficult) to attempt to insert open document searches into the multi-threaded file-based search process. There are significant differences in how the two are implemented. Do you see much practical application for searching the files in a folder, some of which are modified and not saved in Notepad++, merging the search of the unsaved open documents with the search of the unopened files on disk? (For replace I can see the value of skipping open files, as you might have tested the change on a couple files before choosing to apply it to the remaining files. If you already saved the files, you’d be applying the change twice; if you hadn’t saved them, you’d have a bunch of “File has changed, do you want to reload?” prompts to dismiss.) I wonder if any of this works properly when users have multiple instances of Notepad++ open and the files are open in a different instance than the one doing the search?

Microsoft didn’t remove the prompt, but made it configurable, so you can decide if you want to keep it or not. Configuration can be found for example with right click --> properties on the recycle bin icon.

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

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

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

Hi! A bit late, maybe my ZeroBasedColumn plugin could help with what you’re looking for. It makes the column numbering in Notepad++ start from 0 instead of 1. https://github.com/pasqualeambrosio/ZeroBasedColumn Hope it helps!