@harry-brookes , @peterjones “the devil is in the details” And there are more details than I knew existed. The details have details. It’s easy for a naïve multi-threaded implementation to be slower than a single-threaded implementation, as was demonstrated when @guy038 ran a test of my search on a folder on a USB stick. I’m working now on improving it. It’s incredible how many ways there are to shoot yourself in the foot with multi-threading. I’ll feel validated if I can come up with something that is sometimes better than single-threaded and never worse than single-threaded. It remains to be seen if I can do it.

@Coises How and where do I put that?

@Sam-Fourie , It’s been suggested before, as in issue #17430. The developer stated explicitly: It’s not my intesion to “lock” the document by using “Pin a document”. It’s just a way to make the documents grouped in front so users find them more easily. Checked with MS VC Studio, their behaviour is the same as Notepad++, and I think it’s the right behaviour. It works the way the developer wants, and he has rejected the suggestion to make it work the way you want. update: I’m not saying it’s not a good idea. Just that the developer (who is the final decision maker) is the one you’d need to convince. And, given that he’s already rejected the idea, you’d have to come up with something more than “I really want it” to convince him otherwise (and it would have to be posted in the issues tracker, presumably as a reply to the issue I linked, not in the user Community).

Hello, @coises and All, You said : There are limitations, not yet formally documented, to the way Search++ handles encodings for Search in Files: 1. UTF-16 files without a byte order mark are not recognized as such. (They’ll be misread as something else.) 2. UTF-8 files without a byte order mark that contain any invalid UTF-8 sequences will be processed using the system default (ANSI) code page. 3. Pure ASCII files are processed as UTF-8. (This doesn’t matter for Find, but I will have to review it when I implement Replace, since someone might include non-ASCII characters in the replacement text. I think there will have to be a user control to determine whether to promote ASCII to ANSI or to UTF-8.) 4. Files without a byte order mark that are not pure ASCII and contain any invalid UTF-8 characters are processed using the system default code page. No attempt is made to detect whether a different legacy code page is more likely to be correct, or is explicitly declared within the file. Thanks for this extra information ! FYI, during all my tests, the Autodetect character encoding option, in Settings > Preferences… > MISC, was checked and all the files, described in the P.S. section of my previous post, contain a Byte Order Mark ( BOM ). Here is the list of all UTF-16 files of my D: USB key •------------•--------------------------------------------------------------•-----------------•---------------------•--------------------• | | | | Multi-Replace | Search++ / N++ | | BOM | File | Encoding | Matches 'Fi' | Matches 'Fi' | •------------•--------------------------------------------------------------•-----------------•---------------------•--------------------• | FE FF | D:\Plane_0_UCS-2_BE.txt | UTF-16 BE BOM | 2 | 0 | | FE FF | D:\Planes_0+1_UTF-16.txt | UTF-16 BE BOM | 2 | 0 | •------------•--------------------------------------------------------------•-----------------•---------------------•--------------------• | FF FE | D:\862_x64\plugins\NppExec\doc\NppExec\NppExec_HelpAll.txt | UTF-16 LE BOM | 0 | 31 | | FF FE | D:\Plane_0_UCS-2_LE.txt | UTF-16 LE BOM | 2 | 0 | | FF FE | D:\862_x64\plugins\Config\npec_cmdhistory.txt | UTF-16 LE BOM | 0 | 0 | | FF FE | D:\862_x64\plugins\Config\npes_last.txt | UTF-16 LE BOM | 0 | 0 | •------------•--------------------------------------------------------------•-----------------•---------------------•--------------------• | | Total | | 3 Files / 6 hits | 1 File / 31 hits | •------------•--------------------------------------------------------------•-----------------•---------------------•--------------------• Notes : The correct results are reported in the last column My USB key also contains 49 UTF-8-BOM files ( EF BB BF ) correctly detected by all the search engines ! Now, based on my test, have you conducted any similar tests of your own, and have you found that searching with Search++ also takes longer compared to the native search in N++ ? Of course, I can run more tests myself, but I imagine your tests would be more valuable and might, perhaps, give you some ideas on how to increase the overall search speed with Search++ I’m really curious to hear your own observations ! Best Regards, guy038

Seems they decided that it they couldn’t be the heroes, rhat they would be the villains.