@behrouz1 , I didn’t notice: you are using dark mode. overrideMap.xml needs to point to Markdown (preinstalled dark mode) as the UDL name.

Now the plugin supports the Dark Mode by means of “SmartMath_Dark.udl.xml” (in addition to “SmartMath.udl.xml” which is the light one) and automatically applies either light or dark one. This is achieved by listening to NPPN_DARKMODECHANGED and requesting NPPM_ISDARKMODEENABLED to understand whether the dark UDL or the bright UDL to apply. A screenshot: [image: 1788983575005-055b172d-4091-4e16-a090-23e678758707-image.jpeg] Feel free to propose better colors if you are good in that :) The UDLs are here: https://github.com/d0vgan/npp-smart-math/tree/feature/powerful-calc/Notepad%2B%2B/userDefineLangs

@guy038 said: As for the first bug, I humbly apologize for the inconvenience caused : it’s my own fault. There’s no bug at all ! Maybe, maybe not. I forgot about a Notepad++ setting. I would guess that you have Settings | Preferences… | Editing 1 | Keep selection when right-click outside of selection checked. If I check that box, behavior is consistent with what you reported. Is that a bug? Scintilla normally responds to a right-click by clearing any selection and placing the caret at the position of the right-click, unless the right-click is within an existing selection. Notepad++ specifically captures right-clicks and overrides that behavior when that box is checked, so that right-click effectively behaves just like pressing the context menu key or Shift+F10, ignoring where you right-clicked and basing the context menu on the selection or caret location. I’m inclined to think that if someone has that box checked they probably know what to expect… but then, you didn’t. I haven’t yet investigated, but I suspect it would be possible to bypass that setting by capturing the actual screen location of the right-click, converting that to a character position, and acting accordingly. The question is, should I? To end, could you verify if you can reproduce the third bug or if I forgot something obvious ? Now, if you change the search string and try again to select the default Show option, NO change occurs at all. You need to first cancel the previous Show operation by running, within the Tools dialog, the Remove marks and bookmarks from active document option Then the Show feature applied to the modified search is correctly performed ! This isn’t really a bug, but a “feature” of questionable utility. Commands with default scope apply to marked text if there is any marked text, unless Settings | Marked Text | Default commands automatically search within marked text. is not checked. So most likely you see “No matches found in marked text.” at the bottom of the dialog when you attempt your second Show. If you used Show in Whole Document it would have worked. I agree, this is probably confusing. I didn’t want different default scope commands to behave differently, but this does seem like an exceptional case. I already have a checkbox for Allow default Mark command to Mark in Marked Text; I should probably have a similar Allow default Show command to Show in Marked Text, unchecked by default. Perhaps I should redesign this whole default scope concept. I just don’t know how to keep it flexible and convenient and user-friendly all at once. (I include a reasonably clean design, as in “dialog not so cluttered with buttons and options that your eyes hurt just looking at it” as part of user-friendly. Yet so is minimizing the “User Astonishment Factor”: as in, “Wow, I never expected that to happen!”)

Hello, @francisco, @gerdb42 and All, There are plenty of solutions ! The following one will ensure that the . matches newline option will not be used even it’s checked and that the Match case option is enabled even it’s not checked ! FIND (?-si)_.+(?=\.txt) REPLACE Leave EMPTY Best Regards, guy038

@Midnitecata said: @PeterJones thank you for your help, ill probably steer clear of it just out of caution, but i might look into it further should the tedious formatting inconvenience me enough to learn how to spot malicious code! thanks again!! :) Just a side note to this discussion: While you certainly can manipulate *.srt files in Notepad++ (and I do on occasion), for most purposes the free and open source program Subtitle Edit (found here on GitHub) is much easier to use. It has many functions for doing things like shifting times, identifying likely errors, and so on. Before working too hard to find a way to do something with a subtitle file in Notepad++, I recommend checking first to see if Subtitle Edit already knows how to do it.

Hello, @blake-g.-barrington, @peterjones, @coises and All, Here is my version to get duplicate lines, separated by any number of lines ( whatever they are : true empty lines, blank lines or lines with text ), even zero line : MARK (?-si)^(.+)(?=(.*\R)+\1$) As said by @Peterjones, and after some tests, this kind of regex get into trouble when the bunch of lines, between two duplicate lines, exceeds 15,000 empty lines about ! Now, Let’s suppose you create this text file : first 0002 0003 0004 0005 .... .... .... 9997 9998 9999 10000 first Then the (?-si)^(.+)(?=(.*\R)+\1$) regex returns : Correct result until the number of the in-between lines does not exceed 1,600, with the message 1 match in entire file Correct result until the number of the in-between lines does not exceed 12,000, although the error message Find Invalid Regular Expression ( So F.I.R.E. !! ) occurs ! NO result at all if the number of lines is over 12,000 lines, with, of course, the error message Find Invalid Regular Expression Best Regards, guy038 P.S. : I should add that my Windows11 laptop has 32 Gb of memory !

@PeterJones I sent him an email but got no reply. Overall I’m a bit disappointed with this. I think for all his good intentions he’s allowing a strong chance of people accidentally clicking on these malware links, Got nothing more to add. Thanks.

@PeterJones, Thank you for your considered (and considerate) engagement. I actually hesitated to respond with my comment about the 70s and 80s, pretty sure I would get what you gave, but I couldn’t resist—I’m old (83 next month). Anyway, thanks again for putting up with me. …lee

@Roberts-Rozis Kudos. I want this feature too. I want to search my source code project, shared, and library folder to one level deep only because the library folder is very wide and deep, quadrupling the search time.

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

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!

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.

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

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

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