@rdipardo Following a comment chain, I ended up adding a request to the markdig libraryhere: https://github.com/xoofx/markdig/issues/952

Hello, @coises and All, Sorry, @coises, but I came acroos some differences of counting, in regex mode, between your two plugins Columns++ and Search++ For my tests, I used my Total_Chars.txt file that you can download from this location : https://drive.google.com/file/d/1DTDQdUMgC-c2Fkc-LvlQghvtwMYyoWi3/view?usp=sharing All countings are run in regex mode with the Match case option enabled Some time ago, I made a list of all Unicode blocks of the last version 17.0. Presently, while testing the MultiReplace plugin of @thomas-knoefel, I updated this list and took the opportunity to include the count results obtained with Search++ alongside those already provided by Columns++ And I was very surprised because there are a lot of differences in the results between your two plugins Columns++ and Search++ !? Here is a non-exhaustive list of the différenes observed : •-------------------------------•----------------------------------------------------•----------•----------• •------------•-----------•-----------• | Block range | Block name | Total | Assigned | | N++ / MRep | Columns++ | Search++ | | | | Code-Pts | Code-Pts | | Word Chrs | Word Chrs | Word Chrs | •-------------------------------•----------------------------------------------------•----------•----------• •------------•-----------•-----------• | (?=\w)[\x{0400}-\x{04FF}] | Cyrillic | 256 | 256 | | 248 ! 248 | 255 | | (?=\w)[\x{0590}-\x{05FF}] | Hebrew | 112 | 88 | | 30 ! 31 | 82 | | (?=\w)[\x{0600}-\x{06FF}] | Arabic | 256 | 256 | | 172 ! 173 | 225 | | (?=\w)[\x{0700}-\x{074F}] | Syriac | 80 | 77 | | 34 ! 34 | 62 | | (?=\w)[\x{0780}-\x{07BF}] | Thaana | 64 | 50 | | 39 ! 39 | 50 | | (?=\w)[\x{07C0}-\x{07FF}] | NKo | 64 | 62 | | 46 ! 46 | 56 | | (?=\w)[\x{0800}-\x{083F}] | Samaritan | 64 | 61 | | 0 ! 25 | 46 | | (?=\w)[\x{0840}-\x{085F}] | Mandaic | 32 | 29 | | 0 ! 25 | 28 | | (?=\w)[\x{0870}-\x{089F}] | Arabic Extended-B | 48 | 43 | | 0 ! 31 | 40 | | (?=\w)[\x{08A0}-\x{08FF}] | Arabic Extended-A | 96 | 96 | | 0 ! 42 | 95 | | (?=\w)[\x{0900}-\x{097F}] | Devanagari | 128 | 128 | | 83 ! 91 | 125 | | (?=\w)[\x{0980}-\x{09FF}] | Bengali | 128 | 96 | | 63 ! 65 | 85 | | (?=\w)[\x{0A00}-\x{0A7F}] | Gurmukhi | 128 | 80 | | 61 ! 61 | 79 | | (?=\w)[\x{0A80}-\x{0AFF}] | Gujarati | 128 | 91 | | 62 ! 63 | 89 | | (?=\w)[\x{0B00}-\x{0B7F}] | Oriya | 128 | 91 | | 63 ! 63 | 84 | | (?=\w)[\x{0B80}-\x{0BFF}] | Tamil | 128 | 72 | | 47 ! 47 | 61 | | (?=\w)[\x{0C00}-\x{0C7F}] | Telugu | 128 | 101 | | 64 ! 68 | 92 | | (?=\w)[\x{0C80}-\x{0CFF}] | Kannada | 128 | 92 | | 63 ! 68 | 91 | | (?=\w)[\x{0D00}-\x{0D7F}] | Malayalam | 128 | 118 | | 69 ! 77 | 100 | | (?=\w)[\x{0D80}-\x{0DFF}] | Sinhala | 128 | 91 | | 59 ! 69 | 90 | | (?=\w)[\x{0E00}-\x{0E7F}] | Thai | 128 | 87 | | 83 ! 67 | 83 | | (?=\w)[\x{0E80}-\x{0EFF}] | Lao | 128 | 83 | | 50 ! 66 | 83 | | (?=\w)[\x{0F00}-\x{0FFF}] | Tibetan | 256 | 211 | | 59 ! 60 | 137 | | (?=\w)[\x{1000}-\x{109F}] | Myanmar | 160 | 160 | | 94 ! 94 | 152 | | (?=\w)[\x{1200}-\x{137F}] | Ethiopic | 384 | 358 | | 326 ! 326 | 329 | | (?=\w)[\x{16A0}-\x{16FF}] | Runic | 96 | 89 | | 78 ! 83 | 86 | | (?=\w)[\x{1700}-\x{171F}] | Tagalog | 32 | 23 | | 17 ! 19 | 23 | | (?=\w)[\x{1720}-\x{173F}] | Hanunoo | 32 | 23 | | 18 ! 18 | 21 | | (?=\w)[\x{1740}-\x{175F}] | Buhid | 32 | 20 | | 18 ! 18 | 20 | | (?=\w)[\x{1760}-\x{177F}] | Tagbanwa | 32 | 18 | | 16 ! 16 | 18 | | (?=\w)[\x{1780}-\x{17FF}] | Khmer | 128 | 114 | | 64 ! 64 | 97 | | (?=\w)[\x{1800}-\x{18AF}] | Mongolian | 176 | 158 | | 140 ! 139 | 146 | | (?=\w)[\x{1900}-\x{194F}] | Limbu | 80 | 68 | | 39 ! 41 | 65 | | (?=\w)[\x{1A00}-\x{1A1F}] | Buginese | 32 | 30 | | 23 ! 23 | 28 | | (?=\w)[\x{1A20}-\x{1AAF}] | Tai Tham | 144 | 127 | | 0 ! 74 | 114 | | (?=\w)[\x{1AB0}-\x{1AFF}] | Combining Diacritical Marks Extended | 80 | 58 | | 0 ! 0 | 58 | | (?=\w)[\x{1B00}-\x{1B7F}] | Balinese | 128 | 127 | | 64 ! 65 | 96 | | (?=\w)[\x{1B80}-\x{1BBF}] | Sundanese | 64 | 64 | | 42 ! 48 | 64 | | (?=\w)[\x{1BC0}-\x{1BFF}] | Batak | 64 | 56 | | 0 ! 38 | 52 | | (?=\w)[\x{1C00}-\x{1C4F}] | Lepcha | 80 | 74 | | 49 ! 49 | 69 | | (?=\w)[\x{1CD0}-\x{1CFF}] | Vedic Extensions | 48 | 43 | | 0 ! 13 | 42 | | (?=\w)[\x{1DC0}-\x{1DFF}] | Combining Diacritical Marks Supplement | 64 | 64 | | 0 ! 0 | 64 | | (?=\w)[\x{2000}-\x{206F}] | General Punctuation | 112 | 111 | | 0 ! 0 | 5 | | (?=\w)[\x{20D0}-\x{20FF}] | Combining Diacritical Marks for Symbols | 48 | 33 | | 0 ! 0 | 33 | | (?=\w)[\x{2150}-\x{218F}] | Number Forms | 64 | 60 | | 41 ! 2 | 41 | | (?=\w)[\x{2460}-\x{24FF}] | Enclosed Alphanumerics | 160 | 160 | | 0 ! 0 | 52 | | (?=\w)[\x{2C80}-\x{2CFF}] | Coptic | 128 | 123 | | 101 ! 107 | 110 | | (?=\w)[\x{2D30}-\x{2D7F}] | Tifinagh | 80 | 59 | | 55 ! 57 | 58 | | (?=\w)[\x{2DE0}-\x{2DFF}] | Cyrillic Extended-A | 32 | 32 | | 0 ! 0 | 32 | | (?=\w)[\x{3000}-\x{303F}] | CJK Symbols and Punctuation | 64 | 64 | | 22 ! 9 | 28 | | (?=\w)[\x{3040}-\x{309F}] | Hiragana | 96 | 93 | | 89 ! 89 | 91 | | (?=\w)[\x{A640}-\x{A69F}] | Cyrillic Extended-B | 96 | 96 | | 69 ! 78 | 94 | | (?=\w)[\x{A6A0}-\x{A6FF}] | Bamum | 96 | 88 | | 0 ! 70 | 82 | | (?=\w)[\x{A800}-\x{A82F}] | Syloti Nagri | 48 | 45 | | 32 ! 32 | 41 | | (?=\w)[\x{A880}-\x{A8DF}] | Saurashtra | 96 | 82 | | 60 ! 60 | 80 | | (?=\w)[\x{A8E0}-\x{A8FF}] | Devanagari Extended | 32 | 32 | | 0 ! 9 | 28 | | (?=\w)[\x{A900}-\x{A92F}] | Kayah Li | 48 | 48 | | 38 ! 38 | 46 | | (?=\w)[\x{A930}-\x{A95F}] | Rejang | 48 | 37 | | 23 ! 23 | 36 | | (?=\w)[\x{A980}-\x{A9DF}] | Javanese | 96 | 91 | | 0 ! 58 | 76 | | (?=\w)[\x{A9E0}-\x{A9FF}] | Myanmar Extended-B | 32 | 31 | | 0 ! 30 | 31 | | (?=\w)[\x{AA00}-\x{AA5F}] | Cham | 96 | 83 | | 62 ! 62 | 79 | | (?=\w)[\x{AA60}-\x{AA7F}] | Myanmar Extended-A | 32 | 32 | | 0 ! 26 | 29 | | (?=\w)[\x{AA80}-\x{AADF}] | Tai Viet | 96 | 72 | | 0 ! 61 | 70 | | (?=\w)[\x{AAE0}-\x{AAFF}] | Meetei Mayek Extensions | 32 | 23 | | 0 ! 14 | 21 | | (?=\w)[\x{ABC0}-\x{ABFF}] | Meetei Mayek | 64 | 56 | | 0 ! 45 | 55 | | (?=\w)[\x{FB00}-\x{FB4F}] | Alphabetic Presentation Forms | 80 | 58 | | 56 ! 56 | 57 | | (?=\w)[\x{FE00}-\x{FE0F}] | Variation Selectors | 16 | 16 | | 0 ! 0 | 16 | | (?=\w)[\x{FE20}-\x{FE2F}] | Combining Half Marks | 16 | 16 | | 0 ! 0 | 16 | | (?=\w)[\x{FE30}-\x{FE4F}] | CJK Compatibility Forms | 32 | 32 | | 0 ! 0 | 5 | | (?=\w)[\x{FF00}-\x{FFEF}] | Halfwidth and Fullwidth Forms | 240 | 225 | | 172 ! 172 | 173 | •-------------------------------•----------------------------------------------------•----------•----------• •------------•-----------•-----------• | (?=\w)[\x{102E0}-\x{102FF}] | Coptic Epact Numbers | 32 | 28 | | 0 | 0 | 1 | | (?=\w)[\x{10330}-\x{1034F}] | Gothic | 32 | 27 | | 0 | 25 | 27 | | (?=\w)[\x{10350}-\x{1037F}] | Old Permic | 48 | 43 | | 0 | 38 | 43 | | (?=\w)[\x{103A0}-\x{103DF}] | Old Persian | 64 | 50 | | 0 | 44 | 49 | | (?=\w)[\x{1CF00}-\x{1CFCF}] | Znamenny Musical Notation | 208 | 185 | | 0 | 0 | 69 | | (?=\w)[\x{1D100}-\x{1D1FF}] | Musical Symbols | 256 | 233 | | 0 | 0 | 30 | | (?=\w)[\x{1D800}-\x{1DAAF}] | Sutton SignWriting | 688 | 672 | | 0 | 0 | 127 | | (?=\w)[\x{1E000}-\x{1E02F}] | Glagolitic Supplement | 48 | 38 | | 0 | 0 | 38 | | (?=\w)[\x{1E030}-\x{1E08F}] | Cyrillic Extended-D | 96 | 63 | | 0 | 62 | 63 | | (?=\w)[\x{1E100}-\x{1E14F}] | Nyiakeng Puachue Hmong | 80 | 71 | | 0 | 63 | 70 | | (?=\w)[\x{1E290}-\x{1E2BF}] | Toto | 48 | 31 | | 0 | 30 | 31 | | (?=\w)[\x{1E2C0}-\x{1E2FF}] | Wancho | 64 | 59 | | 0 | 54 | 58 | | (?=\w)[\x{1E4D0}-\x{1E4FF}] | Nag Mundari | 48 | 42 | | 0 | 38 | 42 | | (?=\w)[\x{1E5D0}-\x{1E5FF}] | Ol Onal | 48 | 44 | | 0 | 41 | 43 | | (?=\w)[\x{1E6C0}-\x{1E6FF}] | Tai Yo | 64 | 55 | | 0 | 50 | 55 | | (?=\w)[\x{1E800}-\x{1E8DF}] | Mende Kikakui | 224 | 213 | | 0 | 197 | 204 | | (?=\w)[\x{1E900}-\x{1E95F}] | Adlam | 96 | 88 | | 0 | 79 | 86 | | (?=\w)[\x{1F100}-\x{1F1FF}] | Enclosed Alphanumeric Supplement | 256 | 200 | | 0 | 0 | 78 | •-------------------------------•----------------------------------------------------•----------•----------• •------------•-----------•-----------• | (?=\w)[\x{E0100}-\x{E01EF}] | Variation Selectors Supplement | 240 | 240 | | 0 | 0 | 240 | •-------------------------------•----------------------------------------------------•----------•----------• •------------•-----------•-----------• Notes : Unlike the Plane 0 and Plane 14, the Unicode Plane 1 does not include all the différences : it’s just for testing ! The Plane 2 and Plane 3 give identical results. Although this post focuses on differences between your two plugins, remark that the native Notepad++ search and the MultiReplace search give identical results, throughout all the Unicode planes and blocks. As promised, I’ll give you, very soon, my suggestions and preferences regarding your post ! Best Regards, guy038

MultiReplace 6.1 is out and will land in Plugin Admin with the next Notepad++ release. The focus of this release is Replace All in One Pass, running the whole list in a single left-to-right sweep instead of one full pass per entry, together with a reworked Find/Replace in Files and a handful of list and UI improvements. Several new options live under Plugins > MultiReplace > Settings. Download: Latest build Key Features & Improvements Replace All in One Pass: Runs the whole list in a single pass instead of one full Replace All per entry, so results build on each other left to right. With cat → dog and dog → cat, sequential mode turns “cat dog” into “cat cat”, one pass turns it into “dog cat”. Much faster on large documents. Toggle per tab, right-click the list tab. Use Open Documents: Find/Replace in Files can now work on files already open in Notepad++ as the live document, unsaved changes included, instead of the copy on disk. New checkbox in Settings. Skip Binary Files: New option for Find/Replace in Files (on by default), same detection as ripgrep and VS Code. Also adds UTF-16 detection without a BOM, and skipped files are always reported, broken down by reason. CSV Header Rows: Find/Replace now always searches header rows too. “Header rows to exclude” only protects sorting and duplicate detection. Collapse to File List: New Search Results dock option folding every search block down to just file names and hit counts. Ctrl/Shift-click works in the fold margin, same as Notepad++'s own Search Results panel. Library Mode: “Keep list always visible” can now be switched right from the Use List button’s context menu, no detour through Settings. Add New Row: Takes over the dialog’s current search options instead of starting all off. Find/Replace text still starts empty. Duplicate Row Reporting: A list row that exactly duplicates an earlier enabled one is skipped as before, but the status line now tells you how many rows were skipped. [image: 1789296944806-e15a9d23-6db6-4411-a694-d44fc95300e5-image.jpeg] Issues or suggestions: GitHub. Happy replacing!

@peter-wall said: It works if that setting is off. It works, full stop. You just need to understand the documentation. As ScintillaDoc says for SCI_SETFIRSTVISIBLELINE, “These messages retrieve and set the line number of the first visible line in the Scintilla view. The first line in the document is numbered 0. The value is a visible line rather than a document line.” (emhasis added). The “document line” in Scintilla is the same thing that Notepad++ numbers in the line number column: it’s the real line, no wrapping. The “visible line” is affected by hiding lines and/or wrapped lines: if you have lines hidden in the document, that can decrease the visible line index relative to the document line number; if you have lines wrapped, that can increase the visible line index relative to the document line number. Scintilla has commands like SCI_VISIBLEFROMDOCLINE and SCI_DOCLINEFROMVISIBLE to help transform between the two concepts, and SCI_WRAPCOUNT will help you determine how many visible lines a single document line will become. If you want to turn word wrapping off, set your visible line, then reinstate word-wrapping, that’s fine; but the Scintilla messages provide other ways to allow you to correctly handle visible-line vs display-line.

@Charles-Billow said: I see how to change fonts etc. for the document I am working on, but how do I change the default font/size/ and zoom level as the default for all new documents? The way you phrased that makes me think you might not understand what a text editor is. Text files are stored as the raw text: no individual text file / text-based-document has any concept of its own font or font-size. It is just text, and it is up to the text editor to decide what font or size to use. If you set Notepad++ to use a specific font or font-size, using the dialog that @markusbodensee shared with you, that will affect how Notepad++ displays it, but MS notepad.exe or VS Code or gvim will all use their own font and size, because it’s up to the app, not the file, what font and size to display text in. If you’ve changed the font and size that’s used “in the current document” in Notepad++, you’ve changed the font and size for all documents, new or old, in Notepad++. As far as Zoom level goes: Notepad++ remembers your previous zoom when you exit. But if you’ve set a reasonable font size as your default, then zoom should normally be at 100% (which is the default if you haven’t zoomed in or out yet). If you’re to the point that you start thinking you want to have the default zoom bigger or smaller than 100%, then think to yourself: do you really mean that you should change the font size bigger or smaller, instead? (Then again, some people are still killing trees from their text editor, so if you’re printing to paper, maybe you have one of the few use cases where it makes sense to use a smaller font but larger zoom, or vice versa.)

@PeterJones Thank YOU so much I copy Your overrideMap & udl_markdown in my folder and problem is solved. I wish program by default have this option. Thank you again dear Peter

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

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.