Hello, @murraysobol, @peterjones and All, I corrected, in my first post to @troglo37, the spelling mistake on the word shortcuts.xml and rearranged a few lines to make my description more precise ! Of course, @murraysobol, it’s better to use the second version of my macro. Note, however, that this macro generally replaces a fairly short piece of text with a rather long string of characters ! Therefore, you may need to change a default setting in the Search section of Preferences... if the resulting regular expression becomes too long ! For example, in my last post to @troglo37, the two lines of the test contains, respectively, 124 and 135 chars and the resulting regexes contains, both, 1,612 chars ! So, go to Settings > Preferences... > Searching section. Then, in the part When Find Dialog is Invoked, move to the Max Characters to Auto-Fill Find field from Selection option and modify the default 1024 value to a greater value. Personally, I use the maximum 16383 value ! However, it’s obvious that your initial selection must be as short as possible This macro will be used mainly to get the different spellings of names or surnames ! An exemple with this INPUT text, below : Our friends Šarūnas, Đorđe, Ørjan, Paweł, Ștefania, Ángel and Uğur had already left Our friends Sarūnas, Đorđe, Orjan, Paweł, Ștefania, Ángel and Uğur had already left Our friends Šarunas, Đorđe, Ørjan, Pawel, Stefania, Ángel and Uğur had already left Our friends Šarūnas, Dorde, Ørjan, Paweł, Ștefania, Angel and Ugur had already left Now if I copy, at random, the third line of this INPUT text somewhere else, select that line and run the Global Search macro, I get this regex : (?=[[=O=]])\X(?=[[=u=]])\X(?=[[=r=]])\X(?=[[= =]])\X(?=[[=f=]])\X(?=[[=r=]])\X(?=[[=i=]])\X(?=[[=e=]])\X(?=[[=n=]])\X(?=[[=d=]])\X(?=[[=s=]])\X(?=[[= =]])\X(?=[[=Š=]])\X(?=[[=a=]])\X(?=[[=r=]])\X(?=[[=u=]])\X(?=[[=n=]])\X(?=[[=a=]])\X(?=[[=s=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=Đ=]])\X(?=[[=o=]])\X(?=[[=r=]])\X(?=[[=đ=]])\X(?=[[=e=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=Ø=]])\X(?=[[=r=]])\X(?=[[=j=]])\X(?=[[=a=]])\X(?=[[=n=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=P=]])\X(?=[[=a=]])\X(?=[[=w=]])\X(?=[[=e=]])\X(?=[[=l=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=S=]])\X(?=[[=t=]])\X(?=[[=e=]])\X(?=[[=f=]])\X(?=[[=a=]])\X(?=[[=n=]])\X(?=[[=i=]])\X(?=[[=a=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=Á=]])\X(?=[[=n=]])\X(?=[[=g=]])\X(?=[[=e=]])\X(?=[[=l=]])\X(?=[[= =]])\X(?=[[=a=]])\X(?=[[=n=]])\X(?=[[=d=]])\X(?=[[= =]])\X(?=[[=U=]])\X(?=[[=ğ=]])\X(?=[[=u=]])\X(?=[[=r=]])\X(?=[[= =]])\X(?=[[=h=]])\X(?=[[=a=]])\X(?=[[=d=]])\X(?=[[= =]])\X(?=[[=a=]])\X(?=[[=l=]])\X(?=[[=r=]])\X(?=[[=e=]])\X(?=[[=a=]])\X(?=[[=d=]])\X(?=[[=y=]])\X(?=[[= =]])\X(?=[[=l=]])\X(?=[[=e=]])\X(?=[[=f=]])\X(?=[[=t=]])\X Finally, if you select the 1,079 characters of this regex and open the Find dialog with Ctrl + F, you can easily verify that it matches, successively, the four lines of the INPUT text. Whaooou ;-)) Note that I could have chosen the first, the second or the fourth line, either. The resulting regexes would have matched the four lines of the INPUT text, as well ! Best Regards, guy038

@guy038 said: I’m actually really surprised by Search++'s performance compared to Notepad++, especially when the search involves a complex regular expression. ( 0:16.36 vs 2:08.20 ! ) Please, note that the USB flash drive I used for my test is a fairly old one with a capacity of only 512 Mb, which may not be well-suited for multithreading and would explain the poor results with Search++ In any case, I assume you’re now confident in Search++'s overall performance ! I don’t entirely trust my own results. Why did my USB search in Search++ for the take longer than the search for a([^\r\n])[^\r\n]*b\1? Either the test data is erroneous or spurious, or Search++ is screwing up access to the USB in some way that’s causing it to “choke” and lose performance (what I suspect happened in your test). I’m still trying to work out how to avoid that happening without hurting the performance when reads are fast. To the best of my knowledge, Notepad++ is entirely single-threaded. It’s only ever doing one thing at a time. An i9-9900K can run sixteen threads simultaneously. So for CPU-heavy workloads (complicated regex searches) with lots of files, it’s not at all surprising that a multithreaded approach could be almost eight times faster. Thirteen times faster running a([^\r\n])[^\r\n]*b\1 against an SSD is pretty satisfying, though. :-) I’m probably getting additional gains from using memory-mapped I/O and running Boost::regex directly against the data the operating system maps into memory, while Notepad++ loads every file into a buffer, and from there into an off-screen Scintilla, before running the search through Scintilla’s API instead of directly with Boost::regex. It’s useful to have tests like yours. I won’t be able to test anywhere near all the situations that can occur. What happens when someone searches a OneDrive folder and not all the files are up-to-date? What happens when someone searches a drive that’s mounted over a VPN? What happens when the cat knocks the USB connector loose in the middle of a search? The worst case for all these is that the whole thing either crashes and takes Notepad++ down with it, or locks up and makes the user terminate Notepad++ with task manager — losing any unsaved work in progress. I don’t want to let that happen. I still have a lot to do to “harden” this against things that can go wrong. And that’s not even starting with Replace yet.

@Coises You’re welcome, and thank YOU for promptly creating the new version, and for your plugins in general to begin with! The new one lets me exit without incurring any dialog.