Search++: A work in progress

Coises

@sevem47 said:

First of all thanks to your great work with this plugin.

Thank you for trying it and giving feedback!

Using a docking dialog for different plugins they may share the same space in NPP. If Search++ ist not active, there is just an empty space that is visible for me. Other plugins have a graphical representation that, in addition to the balloon tip, show which plugin is active.

Good point. I will fix that — not necessarily in the very next release, but I will fix it.

Using Search++ I learned about the possibility to show only certain lines in the edit window. Would it make sense to have a marker that identifies that only some lines of a document are displayed after applying Search++ commands.

I might be missing something. Do you find that it is not obvious enough in the document window itself when lines are hidden (the horizontal lines where the hidden lines are)?

sevem47

@Coises said:

I might be missing something. Do you find that it is not obvious enough in the document window itself when lines are hidden (the horizontal lines where the hidden lines are)?

Thanks for your hint; I see, the mistake is on my side! I use a different background color and my eyes are getting older ;-) Therefore I did not see the lines between the text:
My configuration vs. Default theme:
/
Now I know where to look.

Good point. I will fix that — not necessarily in the very next release, but I will fix it.

I know you have a lot of topics on your list that are much more urgent. For me it is a ‘nice to have’. Thanks for your help.

M Andre Z Eckenrode

This post is deleted!

M Andre Z Eckenrode

@Coises

As you know, I recently reported an issue with Search++ in a new, separate topic, but I see that several others have reported various issues in this one (presumably, because it’s still a work in progress). I have a new issue to report, and thought maybe I should ask if you prefer that new issues get reported in their own topic (which is generally my default), or for users to just include them in this one. Do you care one way or the other?

Coises

@M-Andre-Z-Eckenrode said:

@Coises

As you I recently reported an issue with Search++ in a new, separate topic, but I see that several others have reported various issues in this one (presumably, because it’s still a work in progress). I have a new issue to report, and thought maybe I should ask if you prefer that new issues get reported in their own topic (which is generally my default), or for users to just include them in this one. Do you care one way or the other?

Either way is OK with me. I suspect the moderators might prefer to keep discussion confined to this topic, though.

Coises

Search++ version 0.6.4 is available. It is expected to fix the bug reported here.

Even though it seems most people never experience that bug, I still recommend upgrading at the next convenient time, so we will all be testing the same code. It’s always possible that I broke something else.

I am still working on improving the multi-threading for find in files. I’m also trying to decide how best to mitigate a problem wherein Search++ fails to load when a particular Windows redistributable library has never been installed on the system. More updates should be coming before too much longer.

All thoughts, suggestions, comments, criticisms, bug reports and raspberries are welcome, and thank you to everyone willing to give this jalopy a good work-out.

Coises

Search++ version 0.6.5 is available:

Update to ICU 78.3 and use static linking for ICU. This is expected to fix problems some testers have had running Search++ on older systems or on minimal Windows installs (like Windows Sandbox). For most users there will be no functional difference between this version and version 0.6.4.

Note: There are five icu——.dll files in older versions of Search++ that are not used beginning with version 0.6.5; so it is best to delete the existing Search++ folder (or its contents) before copying, rather than copying the new folder over the old one.

Coises

@guy038 said:

Now, I did a test, searching in all files of my D: USB key, with :
The native N++ Find in Files dialog

The Search++ Search in Files dialog

The MultiReplace Find All in Files command
To be sure to process fair tests, I unplung my USB key, re-start my laptop completely, replug my USB key and starts a new N++ session, before running these three Find in Files operations, in turn !

I searched for the Fi string, with the Match case and the Regular expression options checked. I got :
27,112 matches in 833 files of 1,761 searched for the N++ Search Results panel, in 1m 37s

27,112 matches in 833 files of 1,761 files for the Search++ Search++ Results, in 2m 21s

27,087 hits in 835 file(s) for the MultiReplace Search results panel, in 1m 36s

I have been struggling with how to optimize the multithreading of my search for over a month now. Among other things, I’ve found that most everything I thought I was measuring wasn’t what I was actually measuring.

One surprise I only recently discovered was that even if I eject and unplug a thumb drive and then plug it in again. there is still a “first time today” cost in the time it takes to read it. Windows is persisting something and it is able to identify the same drive, even though it’s been unplugged. I don’t know the exact time, but Windows on my machine keeps it for more than an hour and less than 24 hours.

Running a particular test the first time I plugged in a particular USB drive I have, it took 8 minutes and 26 seconds. After ejecting the drive, unplugging it, waiting a moment, plugging it back in and running the exact same test, it took 20 seconds.

This drive appears to take whatever it is that Windows does once a day (?) exceptionally hard. Most drives don’t show anything so obvious. This is the only drive I have tested so far that uses FAT, so that could have something to do with it.

I haven’t yet tested whether rebooting is enough to reset the “once a day” penalty, or if it persists in something that isn’t lost in a reboot. It may have something to do with antivirus, though I haven’t yet proven any such thing.

So I’m wondering, if you happen to remember, whether you tested in the order you listed, or whether you happened to test Search++ first?

In any case, after weeks of running in circles, I think I will soon give up the fight to optimize performance and see what else needs work.

guy038

Hello, @coises, @thomas-knoefel and All,

@Coises, you said :

So I’m wondering, if you happen to remember, whether you tested in the order you listed, or whether you happened to test Search++ first?

Well, since my previous tests were done in July 18, 2026, I don’t remenber exactly the way I used but I suppose that I first tested the native N++ search ! Thus, I decided to conduct a new series of tests. Of course, the results of the entire scan of my D: USB drive, are slightly different. Luckily, the number of matches and files containing the Fi string are identical between the Search++ search and the Notepad++ search

IMPORTANT : I updated Search++ to the last 0.6.5 version, before all these tests

So, this time, I first use the Search++ Find in Files dialog :

I stop and re-start my W11 laptop
I pluged my USB key
I start N++
I ran an entire scan of my D: USB key for the Fi string, using the Search++ plugin

=> I got 27,081 matches in 841 files of 1,772, in 2m 10s

I close N++
I unpluged my USB key
I stop and re-start my W11 laptop
I re-pluged my USB key
I start N++
I ran an entire scan of my D: USB key for the Fi string, using the native Notepad++ search

=> I got 27,081 matches in 841 files of 1,772, in 1m 21s

As you can see, no real difference between these tests and those of July 18 ! On the other hand, this time, the results obtained with the MultiReplace plugin are completely different. After a complete re-start of my machine

I ran an entire scan of my D: USB key for the Fi string, using the MultiReplace plugin

=> I got 18,767 hits in 726 files in 1m 05s. Most of non text files are not scanned at all ?!

I don’t understand these huge differences ? I first suspected that I allowed this option in MultiReplace settings : File Search : Skip files larger than but this option is not set !

Thus, right after this post, I’m going to post to @thomas-knoefel for possible information !

Remark that this present post is saved on a different USB drive to avoid future changes regarding the number of matches of the Fi string !

To end, @coises, you said :

In any case, after weeks of running in circles, I think I will soon give up the fight to optimize performance and see what else needs work.

I totally agree with this wise statement !!

Best Regards,

guy038

guy038

Hello, @coises and All,

@coises, I recommend that you read this GithHub thread about the multiReplace plugin, specifically my following two replies :

In the first post, I asked @thomas-knoefel if the Find in Files search could scan the N++ buffers rather that their equivalents on disk !

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

And, in the second post, I verified that the attached new build, provided by @thomas-knoefel, do scan the N++ buffers, by default !

Could you implement such behavior and add an option to search on N++ buffers, by default OR on saved files on disk, like within N++ v8.9.8 and MultiReplace ?

TIA for your time and work on this topic !

Best Regards,

guy038