Search++: A work in progress

Coises

Fix a pair of errors that caused incorrect results when characters outside the basic multilingual plane were used in a regex replacement string and when a capture group included invalid UTF-8.
Fix problematic behavior for Show file in explorer on the context menu for the file list in the Search in Files dialog when the file list is large. The action could become sluggish or fail to complete and interfere with other activity.
Handle absolute file paths larger than MAX_PATH in Search in Files. (They still won’t open in Notepad++, but there was no reason Search in Files shouldn’t be able to parse them.)
Avoid “configuration file for this plugin was edited” when running multiple instances of Notepad++: only save when the last instance is closing.

Nothing exciting here, and hopefully no new bugs… just some particular fixes.

Apologies to anyone who downloaded 0.6.3 in the short time it was available. I chose a dumb way to detect the last running instance of Notepad++ that was bound to cause a problem sooner or later. In 0.6.3.1 it is replaced with a less dumb way.

Coises

@guy038 said:

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++ ?

I ran some tests this morning because I wanted to get a reference before I start testing changes to the multithread scheduling in Search++ — so I can verify that what is supposed to be better actually is better.

This is Windows 10 Pro, 64 bit, running on a 2019 desktop with a Core i9-9900K and 32 GB RAM.
D is an internal SSD. S is an internal HDD. U is a USB thumb drive. \\PEACOCK is another machine on the same local area network.
The content of the folder Testing2 on each drive is the same. It’s a mix of 3,762 files in 228 folders, 591 MB total. Somewhere around 5% are binary files (dll, exe, png, etc.).
For U, following your lead, I did a “repeat” running the same search immediately after the first; after that, I unplugged and reconnected the drive before proceeding to another test.
I couldn’t conveniently unplug the internal drives, but testing showed no significant variation in successive trials on D, S or PEACOCK.

Some of these results are surprising. (I thought the hard disk would be noticeably slower than the SSD, and I expected to see a repeat of your experience with the USB drive.) I suspect that some specialized knowledge I do not have, and perhaps a more controlled environment, is required to measure performance meaningfully, so all this should be taken as anecdotal.

Search++ 0.6.3.1:

D:\Quick\Testing2     a([^\r\n])[^\r\n]*b\1  0:08.71  149,919 matches in 2,505 of 3,762 files (Regex): a([^\r\n])[^\r\n]*b\1
D:\Quick\Testing2     the                    0:01.44  445,907 matches in 3,342 of 3,762 files (Regex): the
S:\Testing2           a([^\r\n])[^\r\n]*b\1  0:08.91  149,919 matches in 2,505 of 3,762 files (Regex): a([^\r\n])[^\r\n]*b\1
S:\Testing2           the                    0:01.10  445,907 matches in 3,342 of 3,762 files (Regex): the
U:\Testing2           a([^\r\n])[^\r\n]*b\1  0:16.36  149,919 matches in 2,505 of 3,762 files (Regex): a([^\r\n])[^\r\n]*b\1
U:\Testing2 (repeat)  a([^\r\n])[^\r\n]*b\1  0:08.87  149,919 matches in 2,505 of 3,762 files (Regex): a([^\r\n])[^\r\n]*b\1
U:\Testing2           the                    0:24.84  445,907 matches in 3,342 of 3,762 files (Regex): the
U:\Testing2 (repeat)  the                    0:01.03  445,907 matches in 3,342 of 3,762 files (Regex): the
\\PEACOCK\Testing2    a([^\r\n])[^\r\n]*b\1  0:12.32  149,919 matches in 2,505 of 3,762 files (Regex): a([^\r\n])[^\r\n]*b\1
\\PEACOCK\Testing2    the                    0:07.07  445,907 matches in 3,342 of 3,762 files (Regex): the

Notepad++ 8.9.7:

D:\Quick\Testing2     a([^\r\n])[^\r\n]*b\1  1:53:64  Search "a([^\r\n])[^\r\n]*b\1" (149919 hits in 2505 files of 3762 searched) [RegEx]
D:\Quick\Testing2     the                    0:14.14  Search "the" (445907 hits in 3342 files of 3762 searched) [RegEx]
S:\Testing2           a([^\r\n])[^\r\n]*b\1  1:53.99  Search "a([^\r\n])[^\r\n]*b\1" (149919 hits in 2505 files of 3762 searched) [RegEx]
S:\Testing2           the                    0:12.42  Search "the" (445907 hits in 3342 files of 3762 searched) [RegEx]
U:\Testing2           a([^\r\n])[^\r\n]*b\1  2:08.20  Search "a([^\r\n])[^\r\n]*b\1" (149919 hits in 2505 files of 3762 searched) [RegEx]
U:\Testing2 (repeat)  a([^\r\n])[^\r\n]*b\1  1:54.96  Search "a([^\r\n])[^\r\n]*b\1" (149919 hits in 2505 files of 3762 searched) [RegEx]
U:\Testing2           the                    0:31.62  Search "the" (445907 hits in 3342 files of 3762 searched) [RegEx]
U:\Testing2 (repeat)  the                    0:14.16  Search "the" (445907 hits in 3342 files of 3762 searched) [RegEx]
\\PEACOCK\Testing2    a([^\r\n])[^\r\n]*b\1  2:11.36  Search "a([^\r\n])[^\r\n]*b\1" (149919 hits in 2505 files of 3762 searched) [RegEx]
\\PEACOCK\Testing2    the                    0:29.46  Search "the" (445907 hits in 3342 files of 3762 searched) [RegEx]

(The reason for using [^\r\n] instead of . is that Notepad++ and Search++ have slightly different definitions of . when “matches newline” is not in effect: like Columns++, Search++ excludes only the characters that cause a line break in Scintilla, new line and return; while Notepad++ also excludes four other control characters, FF, NEL, LS and PS. The . is noticeably faster, but it returns different results for Search++ and Notepad++, almost certainly due to the binary files in Testing2.)

Edit: Added local area network tests.

guy038

Hello, @coises and All,

Your tests are much more comprehensive than my simple test and yield some interesting results !

In particular, the comparison between Notepad++ and Search++ for searches on a USB drive shows that Search++ outperforms Notepad++, whether the search is complex or simple !

Indeed, we have :

Search++ 0.6.3.1 :

U:\Testing2           a([^\r\n])[^\r\n]*b\1  0:16.36  149,919 matches in 2,505 of 3,762 files (Regex): a([^\r\n])[^\r\n]*b\1
U:\Testing2 (repeat)  a([^\r\n])[^\r\n]*b\1  0:08.87  149,919 matches in 2,505 of 3,762 files (Regex): a([^\r\n])[^\r\n]*b\1

U:\Testing2           the                    0:24.84  445,907 matches in 3,342 of 3,762 files (Regex): the
U:\Testing2 (repeat)  the                    0:01.03  445,907 matches in 3,342 of 3,762 files (Regex): the

And :

Notepad++ 8.9.7 :

U:\Testing2           a([^\r\n])[^\r\n]*b\1  2:08.20  Search "a([^\r\n])[^\r\n]*b\1" (149919 hits in 2505 files of 3762 searched) [RegEx]
U:\Testing2 (repeat)  a([^\r\n])[^\r\n]*b\1  1:54.96  Search "a([^\r\n])[^\r\n]*b\1" (149919 hits in 2505 files of 3762 searched) [RegEx]

U:\Testing2           the                    0:31.62  Search "the" (445907 hits in 3342 files of 3762 searched) [RegEx]
U:\Testing2 (repeat)  the                    0:14.16  Search "the" (445907 hits in 3342 files of 3762 searched) [RegEx]

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 !

Best Regards,

guy038

Coises

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

sevem47

First of all thanks to your great work with this plugin. Going through the help file to learn about all features of the plugin the following ideas came to my mind.

They are about graphical topics that probably are just cosmetical questions.

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. Two images to show my point:
/
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. Something like the following filter symbol to mark that not all lines are visible:

(the image is copied from Total Commander’s function ‘Synchronize directories’)

Just some ideas that would help me in using Search++.

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

Coises

@guy038 said:

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

Yes, that is a condition I have not yet addressed, and it is good that you call it to my attention.

I am more inclined to raise a warning box telling the user that some of the files to be searched are currently open in Notepad++, and the search results (and modifications, when I get Replace in Files done) will apply to the stored files, not to the edits in progress in Notepad++.

The way these searches work would make it difficult (probably not impossible, but difficult) to attempt to insert open document searches into the multi-threaded file-based search process. There are significant differences in how the two are implemented.

Do you see much practical application for searching the files in a folder, some of which are modified and not saved in Notepad++, merging the search of the unsaved open documents with the search of the unopened files on disk? (For replace I can see the value of skipping open files, as you might have tested the change on a couple files before choosing to apply it to the remaining files. If you already saved the files, you’d be applying the change twice; if you hadn’t saved them, you’d have a bunch of “File has changed, do you want to reload?” prompts to dismiss.)

I wonder if any of this works properly when users have multiple instances of Notepad++ open and the files are open in a different instance than the one doing the search?

guy038

Hello, @coises and All,

I understand that focusing on N++ buffers, instead of on saved files on disk, is not really appropriate for your multithreaded approach !

You said :

I am more inclined to raise a warning box telling the user that some of the files to be searched are currently open in Notepad++, and the search results (and modifications, when I get Replace in Files done) will apply to the stored files, not to the edits in progress in Notepad++.

So, given, your constraints, I totally agree ! That seems the more simple and obvious solution, with a Cancel button in case some concerned and opened files are dirty, in current N++ session

On the other hand, you said :

I wonder if any of this works properly when users have multiple instances of Notepad++ open and the files are open in a different instance than the one doing the search?

I personally mainly use N++ in a N++ mono instance so I can’t speak properly of that case. But I agree with you that managing several instances must be a challenge for the Find in Files or Replace in Files feature !

Best Regards,

guy038

Coises

Search++ version 0.6.6 is available:

Add tab icons to the docking search dialog and the results list. (When you have more than one dialog docked to the same edge in Notepad++, the icon shows on the tabs that are not active.)
Fix an error (present since version 0.6) that caused the count of files containing a match in the status message when counting or searching in Files in View or in Open Documents to be one too large.
Various internal updates to Find in Files to make it more robust against I/O errors, with better error reporting.

Thank you to everyone willing to try this work in progress. Comments, critiques and suggestions are always welcome.

Progress on the 0.6.x releases has been slow. Much of that was because I decided to introduce Search in Files in version 0.6 as a multi-threaded process, and I had no real experience writing multi-threaded code. After adding Find in Files, I spent a lot of time trying to improve performance. My eventual conclusion, after much trial and error, is that either it can’t be done, or I can’t figure out how to do it.

Hopefully the next few weeks will produce some visible progress.

To that end, I want to list some things that are on my mind at present. Please comment if you have any thoughts about these (which are important, which are unimportant or misguided, thoughts about how they should work, thoughts about things I’ve missed… and I am pretty sure I’m forgetting something):

Obvious missing features

Implement Replace in Files in the Search in Files dialog.
Ability to save and recall search strings.
- There is already history on the right-click menus. I’m not sure if it should be longer, be longer but on a flyout menu, longer with the first n items on the menu and the rest on a flyout, have a configurable number of items…?
- Would the ability to “pin” history items be useful? (Simpler and faster than a save process.)
- For saving I’m thinking of controlling that through a dialog that would let you name what you save, so you would then recall it by name. Saving would save the Find and Replace strings and the associated settings. It would have to be possible to edit, rename or delete a saved search as well. Recalling would probably be by selecting from a flyout on the right-click menu. Thoughts? Is that too complicated? Should the regular dialog (for searching in documents) and the Search in Files dialog share a single set of saved searches?

Features under consideration

Context in search results: that is, showing one or more lines before or after the line(s) containing a match.
- This would be optional and configurable, but a tricky question is whether it is sufficient to configure it before the search or whether you should be able to request context — either for a specific match or for all matches — directly in the search results window, after the search.
- It seems like it would make sense for this to be available for Show actions, too.
Warn or block when characters used in the find or replace fields are inconsistent with the character encoding of files to be searched. (Right now find proceeds without a warning, and replace uses the substitution character, usually a question mark.)
- Find is tricky, because I would have to parse the regular expression to attempt to determine whether the inconsistent characters are required for a match (so no match is possible) or whether they are only required by some alternatives (which might be intentional, if the same expression is used with files in different encodings). Is it worth doing at all? Would a warning (so I didn’t have to parse, since you could just say to search anyway) be more annoying than helpful?
- Replacing can also be conditional, so do I try to detect that, and if it’s conditional, only warn or block if it actually happens? If replacing in multiple files, it could vastly slow down the process if I have to examine each file first to determine its encoding before beginning the actual replace operation. Is it worth it? Or do I only raise the warning if and when I encounter a file that can’t do the replace as written?
In the main search dialog, when the default action is active for a button (e.g., Find, Count, etc. without a scope qualification like “in Selection” or “in Marked Text”), somehow indicate what the default action would be if you pressed the button right now. That is, Find adapts to work in selection if you have a selection large enough, or in marked text, or in the whole document, but what will it actually do right now? This feels like a big missing thing to me, but I’m a bit stumped as to how to indicate it.
- If a put a general indicator somewhere (it will always be the same for all buttons with default scope), where, and how should it appear? I am very hesitant to take up additional space in the dialog, or to make it any more “busy” than it already is.
- If I show it on each button, how would I distinguish it from the marker that tells you the direct action for the button is a command with a specified scope? (Remember, this has to work for any dark mode color combination the user might pick, and some users are colorblind.)
- Would it be better to show it on the buttons and remove the ability to select an action with other than default scope as the action for a button by shift-clicking the drop-down menu? Does anyone even realize they can shift-click the drop-down menus (the only way to know is to do it by accident or read the help)?
Figure out how to modify Boost.regex to get rid of the dreaded “complexity” message. Make progress responsive during a search (not just between finds, as it is now: Boost.regex as built has no progress callback, so you can only estimate progress after it succeeds or fails to find a match, not while it’s working) and let the user cancel if it’s taking too long.
Figure out how to modify Boost.regex to support Unicode word boundaries, and extend that to plain text searches by translating them into regex searches. (Unicode word boundaries recognize that sequences like “can’t” are a single word; for example, if implemented, a whole word match for “can” wouldn’t match the first three letters of ”can’t”; at present, it does.)
Implement “Unicode compatibility forms” matching. This means being able to search for something like “naive” and have it match “naïve” (or vice versa). I think I would only attempt to implement this, at least at first, for plain text searches (which would be translated to a regular expression the user would not see).

Deficiencies and bugs

Personally, I really like the Show function. It hides all lines and then shows the ones that have matches, also marking the matches. A bit like a Find All with the results list right in the document instead of in a tiny little window at the bottom. But there are problems. I use Scintilla’s hidden lines feature directly. Notepad++ also uses that feature, but it doesn’t provide a way for plugins to use it through Notepad++, and it keeps internal status information that assumes only it is using hidden lines. There appears to be no way to make Notepad++ synchronize its own idea of which lines it thinks are hidden with the actual state of Scintilla. Various bizarre things happen because of this. That leaves me with four choices, none of which are great:
- Remove the Show function entirely.
- Accept that if you use Show, unintended and illogical things can and will happen.
- Petition Don to provide a way for plugins to use hidden lines without confusing Notepad++, which might not be accepted, would probably take a long time even if it is accepted, and even when completed would mean this would only work correctly on versions of Notepad++ at least that new.
- Get “creative” and look for some back-door, hacky way to fix it (which might or might not be possible, and might break without warning when Notepad++ changes something).
Keyboard navigation in the Search++ dialog (the main one that can be docked, not the Search in Files dialog) is clunky and not comprehensive.
- There’s no straightforward way to invoke something like “Select in Marked Text” without using the mouse.
- There’s a setting to focus the document after stepwise Find and Replace, but if you check that then there’s no way to do the next Find or Replace without switching back to the Search++ dialog first. The only way I can think of to manage that would be to add two more menu items, which you could assign to free keyboard shortcuts… as if anyone has any free yet memorable keyboard shortcuts. Doing repeated Find actions while being able to edit immediately in the document after a Find seems like a common task. It should be natural and fluid, but it isn’t.
For Search in Files actions, there is presently no warning about files that are open in Notepad++; the files are processed on disk. This will be more critical when Replace in Files is implemented.
- My thought is to present a warning, with OK and Cancel options, noting that Search in Files only processes files on disk. Note that for Find in Files, the impact is that files that were open with changes would search based on the data on disk, not the live version of the document. Documents that are open in Notepad++ (with or without changes) and are also changed on disk by Replace in Files would show a “File changed” notification when activated in Notepad++.
- Because of the way Search in Files works, it would be complicated to treat files open in Notepad++ differently, but is that something that is really important… important enough to go ahead and make the code more complicated in order to do it, so that files open in Notepad++ are processed as open documents and not as files on disk?
The date selection controls in the Search in Files dialog look awful in dark mode. Unfortunately, it turns out the Windows control I used is just about impossible to render in dark mode. (At least, I haven’t found a single example in open source of someone doing it successfully.) So I expect to replace it with something simpler, more like a text control with a drop-down history, where you just type the date.
- Would it be useful to be able to enter the time, and not just the date, to limit which files are examined?
- Would a single universal format (yyyy-mm-dd) be good, or is it an important user amenity to be able to enter dates in your locale format (e.g., mm-dd-yy in the US, dd-mm-yy in most other places)?
- Would you miss the drop-down calendar control? Would you miss having up/down arrows (spin control) for the elements of the date and thus needing to type the numbers to change the date?
- Does anybody even think the date filter is useful in the first place? Do I need a way to take a date from a specific file, rather than the user knowing what dates are wanted, to make it useful?

guy038

Hello, @coises and All,

This morning, I just downloaded your last v0.6.6 release. I was studying your post in order to give you my suggestions and preferences when I came across three bugs :

When you perform a Find All operation and do a right click in the Search++ Results panel, either on an Occurrence(s) line, on a File line ( green line ), or the Title line of the search ( olive line ), the context menu begins with these two lines :

Locate in Document        Enter

Move Here in Document     Shift + Enter

Personally, this case should occur on numbered lines only and not on any green/olive line !?

Now, right click, on either the EMPTY olive/green zone : the context menu begins, now, with the lines :

Expand/Collapse Search       Enter

Expand/Collapse Documents    Shift Enter

This is the expected behavior

But, if you right click again on any numbered line, you get :

Expand/Collapse Search       Enter

Expand/Collapse Documents    Shift Enter

and NOT :

Locate in Document        Enter

Move Here in Document     Shift + Enter

Finally, right click on the grey zone of line numbers. Again, the first two options of the context menu are :

Locate in Document        Enter

Move Here in Document     Shift + Enter

Move the mouse and right click on any line : again, you get the expected result :

Locate in Document        Enter

Move Here in Document     Shift + Enter

The second bug is a bit strange : it modifies the vertical navigation within the N++ files !

Click on the ▼ on the right of the Find All button and run the default Show option

Now, at the top, click on the Tools button and run Show All Lines option

From now on, if you hit the ↑ or ↓ keys, the caret does not move : it’s the document which go upward or downward !?

Swapping to an other file does not change the navgation, even choosing again the Search++ Select or Mark options. Nor closing and re-opening the file. The only way is to close and re-open our beloved editor !

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 !

I just hope that all the oddities will be easy enough to fix !

Best Regards,

guy038

P.S. :

Once I’ve finished reading your latest post, I’ll let you know what I think !

Coises

@guy038 said:
When you perform a Find All operation and do a right click in the Search++ Results panel, either on an Occurrence(s) line, on a File line ( green line ), or the Title line of the search ( olive line ), the context menu begins with these two lines :
Locate in Document        Enter

Move Here in Document     Shift + Enter

I can’t reproduce this one. What should happens is that search (gold) lines should show:
    Expand/Collapse Search
    Expand/Collapse Documents
while file (green) lines should show:
    Expand/Collapse Document
    Open Document
and match (numbered) lines should show:
    Locate in Document
    Move Here in Document
when you right-click. That is what is happening on my machine.

I wonder if you could check something for me. When you press the right mouse button down in the Search++ Results window, does the caret indicator immediately move to the place where you clicked (even before the menu displays, which happens when you release the mouse button)? (Note: if you click in the left margin or past the right end of the text on a line, the caret is expected to move to the beginning or end of the line, respectively.)

If that’s not happening, it would explain why you’re getting unexpected options on the menu (since the menu is based on the caret location), but then I need to figure out why your caret isn’t following the right-click. The only time that’s expected is if you right-click within an existing selection: in that case, the selection should remain as is.

The second bug is a bit strange : it modifies the vertical navigation within the N++ files !

Click on the ▼ on the right of the Find All button and run the default Show option

Now, at the top, click on the Tools button and run Show All Lines option

From now on, if you hit the ↑ or ↓ keys, the caret does not move : it’s the document which go upward or downward !?

Thank you for the report! I can reproduce that. I hadn’t noticed it before, but I suspect it is related to a different bug that’s been puzzling me: when I use Show and then later Show All Lines, afterward whenever I make an alteration in the text (type something new) the text jumps to a new position on the screen. Hopefully I’ll be able to put what you’ve just told me together with that and find the cause, and a way to fix it.

Edit to add: How did I not find this before? In Show All Lines I change something called the caret policy in order to make sure that when I show the lines, the place where you had the caret will still be on the screen. I neglected to change it back to what it was afterward.

I will fix that for the next release. Thank you for the report… I don’t know why I didn’t recognize where the problem was before, but something in the way you described it jogged my brain cells.