Search++: A work in progress

guy038

I re-tested the supposed bug and I simplified the procedure which is necessary to trigger that bug !

If opened, close the Search++ plugin by clicking on the cross, at the far right
A Re-open Search++ with the Plugins > Search++ > Search... option
B Try to close the Search++ panel by clicking on the cross, at the far right => Nothing happens !?
C After some trys, if you move slightly the mouse, you should be able to close the Search++ panel

Sometimes, you’ll need to repeat the actions A ato C, up to 5 times consecutively, to trigger that bug. but this event may also occur at the first try !

I also noted that, when the bug occurs, any subsequent left click on the cross does nothing until I move very slightly the mouse, without any clicking, that is enough, then, to close the search++ panel by clicking againg onto the cross icon. Very strange, indeed !?

As I suspected that the problem could be an hardware issue with my bluethooth mouse, I disabled it and installed a classical USB mouse, instead. But, unfortunately, results were identical as well as the uncertainty regarding the manifestation of the bug !

I have different portable versions of Notepad++, but the one which is concerned is the v8.9 release where I installed, both, your Columns++ and Search++ plugins

Here is my Debug info :

Notepad++ v8.9   (64-bit)
Build time: Jan 10 2026 - 02:25:19
Scintilla/Lexilla included: 5.5.8/5.4.6
Boost Regex included: 1_90
pugixml included: 1.15
nlohmann JSON included: 3.12.0
Path: D:\890_x64\Notepad++.exe
Command Line: 
Admin mode: OFF
Local Conf mode: ON
Cloud Config: OFF
Periodic Backup: OFF
Placeholders: OFF
Scintilla Rendering Mode: SC_TECHNOLOGY_DIRECTWRITE (1)
Multi-instance Mode: monoInst
asNotepad: OFF
File Status Auto-Detection: cdEnabledNew (for current file/tab only)
Dark Mode: OFF
Display Info:
    primary monitor: 1920x1080, scaling 125%
    visible monitors count: 1
    installed Display Class adapters: 
        0001: Description - Intel(R) Iris(R) Xe Graphics
        0001: DriverVersion - 32.0.101.7084
OS Name: Windows 11 Pro (64-bit)
OS Version: 25H2
OS Build: 26200.7462
Current ANSI codepage: 1252
Plugins: 
    mimeTools (3.1)
    NppConverter (4.7)
    NppExport (0.4)
    ComparePlus (2.2)
    ColumnsPlusPlus (1.3.1)
    NppUISpy (1.2)
    MultiReplace (4.6.0.33)
    Marginalize (1)
    Search++ (0.5.5)

Finally, note that this portable version of N++ is installed on an USB drive

Best Regards,

guy038

Lachlanmax

@guy038, @coises and all,

I use the dark mode display for almost all apps and I really like it, so I think we are in agreement :)

You know what they say - join the dark mode, we have cookies… 🍪

On another note, I would like to hear your thoughts as veterans on this forum. I’m working on an AI chat plugin to streamline the use of prompting an LLM into the workflow with N++. I wonder - has anyone done it before? What would be important features to implement?

I would appreciate hearing your thoughts.

Thank you!

guy038

Hello, @lachlanmax and All,

Well, presently I’m not a modern C++ developer and I rather use the old Microsoft Qbasic or sometimes the GAWK software and, more rarely, the N++ PythonScript, in addition to N++ and its plugins, of course !

However, I’ve got some documentation on C/C++. So, I’ll probably learn a lot from scratch but I’m not sure yet if I’ll be able to make improvements to our beloved editor !

So, to my mind, you should get in touch with @Richárd-stockinger and @jw which already developed AI tools for N++. They will surely provide you with valuable advice for your project ! Refer to :

https://github.com/krazal/nppopenai

https://github.com/Qdthon/Notepad-AIPlugin

Best Regards,

guy038

P.S. :

Although you might assume that some of my regex solutions seem to have been created with the help from an IA engine, I can assure you that it’s only my modest brain that’s at shake when it comes to these resolutions !

Lachlanmax

@guy038
I wasn’t familiar with these projects. Thank you for the tip-off, I have a lot to learn from these. Glad I asked your advice.

We don’t know each other too well yet, but from your replies I get the feeling you have been coding for a while now… as a relative n00b I think it’s good to learn coding the nuts-and-bolt way, not just “vibe coding” like everyone is nowadays. (Even though I’m developing an AI plugin, so a bit of a contradiction. But I like to develop plugins that I would use personally, and I don’t use it to “vibe code”. Granted though that some might.)

tl;dr Hard work pays off!

guy038

Hi, @lachlanmax and All,

I forgot to give you the Community threads of, both, @Richárd-stockinger and @jw :

https://community.notepad-plus-plus.org/topic/24444/new-plugin-nppopenai

https://community.notepad-plus-plus.org/topic/27361/ai-plugin

BR

guy038

guy038

Hello, @coises and All,

How are you, @coises ? Pretty good, I guess ! I just uploaded a new version of the ICU.txt file which simply corrects a few typos.

https://drive.google.com/file/d/1_TwEV1oorsoWUUjL97BmptcR4fpNQ98_/view?usp=sharing

First, regarding the bug I mentioned in my two previous posts, I also detect it with native N++ and, for example, the Find Results panel :

Open the Find dialog
Do any kind of search
Click on the Find All in Current Document button

=> A Search results panel opens and displays all the occurrences of the searched string

Now :

(1) First, click once, anywhere on the blue Search results title
(2) Then, moving your mouse horizontally right to the cross, at the far right, try to close the panel => Nothing happens !
(3) Just, move down the mouse within the Search results panel then re-click on the cross => This time, the Search results panel should close, as expected.
Re-open the Search results panel, using the F7 key
Repeat the actions, 1, 2 and 3 to trigger again that bug. Sometimes, some tries are necessary to get into the problem !

Remark :

If, you accidentally double click on the Search results title bar, this panel will become a floating window. To restore its initial position, simply double-click again on the Search results title bar

Note that, in the end, this bug does not really matter because I mapped the Ctrl + Shift + N shorctut to the Search... option of your plugin. So, hitting this shortcut twice does close the plugin, anyway !

I thought of an enhancement of your Search++ plugin :

Let’s suppose that I want to mark all lines which satisfy the regex below, against the latest change.log file ( release 8.9.6 ). So :

We open or select the change.log file / tab
We open the Mark dialog ( Ctrl + M )
We check the Bookmark line, Purge for each search and Wrap around options, ONLY
MARK (?i-s)(?:\G|Q).*?T
We select the Regular expression mode
Finally, we click on the Mark All button

Two lines only are bookmarked : the very first one and the point #8 of v8.9.4. However, the total number of occurrences is 8

Notepad++ v8.9.6 vulnerability fix, regression fixes & bug-fixes:
 8. Fix quote escaping causing incorrect JSON syntax highlighting (Lexilla update related).

As you can see :

For the first line, as we are at the very begining of file, the \G alternative finds two occurrences
For the second line, the Q alternative finds the first occurrence and the \G alternative finds the five remaining occurrences

So, I was wondering if you could alternate the colors, between the present mark color and an other one, in order to easily distinguish these occurrences ?

Now, near the end of your initial Search++ post, you said :

I plan to add a Save function that will let you save searches you might want to use again. Of course, once it is possible to save, it has to be possible to delete and rename and edit and organize… I haven’t designed a user interface for any of that yet.

I do support this future enhancement !

Best Regards,

guy038

Coises

@guy038 said:

So, I was wondering if you could alternate the colors, between the present mark color and an other one, in order to easily distinguish these occurrences ?

I have thought about the possibility of making marks designate individual spans of text rather than running together. It is possible. In fact, you can see it, if you look closely, in the Search++ search results window if you do a Find All with the change log and your regular expression. You might have to zoom to see it, but there are small white spaces between the different matches. The search results window also marks null matches with an upward-pointing chevron below the baseline.

Your idea makes sense. I believe I would have to make it an optional feature, because it is not the way marking ordinarily works in Notepad++. I also have to consider how it impacts search in marked text, though I think that would be straightforward: when marked text is separated in this way, each individual span would be searched independently. (In the current way of marking, each contiguous marked block is searched regardless of whether it came from a single match or multiple matches.) It will take some thinking to make sure what happens when marked text is already present and new marks are added which adjoin or overlap existing marks makes sense.

I do support this future enhancement

As you’ve no doubt noticed, there hasn’t been any progress on Search++ lately. I had hoped that following the point where I made the first public release I would be able to just keep going straight through to a first “stable” release, but my attention has been directed elsewhere for a time. I’ll be back.

Find/replace in files and saving searches are the two main features I want to add before I think I can close in on “stable.” These are both things that I think could cause significant changes in the programming (and maybe the user interface), so I don’t want to try to reach “stable” and then immediately destabilize everything. I’m treating their absence as a blocker.

I think I want to add a couple more options for manipulating marked text (like remove marks from selected text) to the Tools menu, and I have some known problems (like that the search results window can be painfully slow with a lot of matches in a large file, and I don’t think the routine that is supposed to make finding a match scroll so that the match won’t be hidden behind the dialog when it is non-docking works reliably yet). ICU search should either be hidden or be extended to work with most if not all of the same commands as Regex (Boost).

There is still no simple way to access the drop-down menus on the split command buttons by keyboard, and I still don’t have a good idea how to make it both possible and discoverable. I think I need to add Find and Replace commands to the plugin menu so it would be possible to set them as Notepad++ shortcuts, which would make it possible to do sequential find and/or replace while focus remains in the document.

Your suggestion here makes sense, and I need to crawl through this entire topic to see what other ideas and observations I might have forgotten. There was a suggestion in another topic about showing context (lines before and after) in the search results list: I’ll probably look at that when I look at search in files, since both will require significant changes to the way I build the search results list at present.

Coises

@guy038 said:

First, regarding the bug I mentioned in my two previous posts, I also detect it with native N++ and, for example, the Find Results panel :

Thank you for that additional information. I had a suspicion this was a Notepad++ behavior not really related to the plugin.

I have not been able to reproduce it. It is possible that it is dependent on some detail of your operating system or drivers.

Since you can reproduce it without any plugin, I suggest adding it as a Notepad++ issue if you think it is worth further investigation. It could be that others will be able to reproduce it, perhaps including someone who can run Notepad++ under debug and close in on what is going wrong.

Coises

Search++ version 0.6 is available.

The big change in this version is the addition of a Search in Files dialog:

There have been a few small fixes elsewhere — by now I’ve forgotten what they were — but mostly this release is for Find in Files. Adding that led to quite a few changes in code it shares with the existing functions, so unfortunately there could be new bugs in old functions. On the whole, though, handling of the search results list should be improved for all functions that use it.

If you don’t like to read help, at least don’t forget to try right-clicking the text entry boxes and items in the file list.

Replace in Files is planned but not yet implemented.

guy038

Hello, @coises and All,

First, many thanks for adding the Find in Files capability within the Search++ plugin. In addition, this search dialog allows you to filter by date range and/or size and also to choose or exclude some extensions !

Regarding the Search++ Search in Files dialog :

To my mind, the magic option is the last Filter Reg. Exp. option. Indeed, for example, from my USB key named D:, I typed in the text below, in the Filters zone :

^890_x64\\.+\.log$|^862_x64\\|^C.*\.txt

Then, the search scope would be :

All the .log files in the 890_x64 arborescence of D:
All files of the 862_x64 folder of D:
All the txt files, from the root ( D: ), whose name starts with a letter C

It’s important to emphasize that the Filters search is always a NON-SENSITIVE search. Thus, given the example above, the search would occur on file D:\..\...\...\Test.LOG and on file D:\current.txt. This remark also applies to the Extensions and Exclude options !

In order to search in a specific folder, named Music of my USB key, I have two possibilities :

Clic on the Browse button in the Folder zone, select the Music folder and choose the option None in the Filter zone
Type in D:\ ( the root ) in the Folder zone, choose the Filter Reg. Exp. option and type in ^Music\\ in the dialog

But if you’re looking for any directory of your media, with name Music, prefer this regex (^|.*\\)Music\\

Note that if you type in, for example, log;ini in the Filter Extensions option, you may use, instead, the Reg. Exp. option with the regex \.(log|ini)$

Now, is there a particular reason for not allowing the ICU search ? For some European people, the search of any text depending of a specific language could be interesting !

For example, the different searches, below, would find any file containing GREEK characters :

All Greek blocks [[[\p{In_Greek}][\p{In_GreekExt}][\p{In_AncientGreekNumbers}][\p{In_AncientGreekMusic}]]&&[\p{Assigned}]] ( = 135 + 233 + 79 +70 = 517 characters )
The Greek script \p{Grek} ( = 518 characters )
The Greek Extended script \p{SCX=Grek} ( = 531 characters )

Regarding the Search++ Results dialog :

Would it be possible to add a Purge option, like in the context menu of the N++ Search results dialog ? You could use the same label Purge for every search or some equivalent ( I do like Purge before each search )
Although written in your files list, I also noted that the number of scanned files is not reported in the Search++ Results** dialog, unlike with the N++ **Search results` dialog

For instance, the search of the string Fi within all files of my USB key gives :

- Finished; found 34 283 matches in 841 of 1771 files. in the FILE list of Search++

- 34 283 matches in 841 files: Fi, on the FIRST line of the Search++ Results dialog

- Search "Fi" (34283 hits in 841 files of 1771 searched) [RegEx: Case], on the FIRST line of the N++ Search Results

And, if possible, it would be best to include the chosen options of the current regex too, like Regex, Case,... ?!

To end with, I noticed that, within the N++ Search results, it is possible to easily see all files which has matches, without seeing the matched lines :

By hitting Ctrl and clicking on ⊟, on the first line => The search collapsed after some time and then with a simple click on ⊞
By using the Fold All option of the Context dialog and then a simple click on ⊞ of the first line

Although, within the Search++ Results dialog, you can double-click on any file header or on the Search header itself to collapse the lines, I have not been able to get the configuration below, in the Search+++ Results panel :

⊞ D:\Micro.txt
⊞ D:\862_x64\npp.8.6.2.portable.x64.7z
⊞ D:\862_x64\autoCompletion\actionscript.xml
...
...
...
⊞ D:\change_896.log
⊞ D:\Word_Frequency.txt

As usual, @coises, these ideas are only suggestions. Do as you like, of course !

Best Regards

guy038

Coises

@guy038 said:
First, many thanks for adding the Find in Files capability within the Search++ plugin.

Thank you for trying it!

It’s important to emphasize that the Filters search is always a NON-SENSITIVE search.

I made it that way by default since file and folder names are not case sensitive in Windows. You can still prefix the expression with (?-i) to make it case sensitive. I don’t know if the API I use to retrieve file paths from a folder is guaranteed always to return names in the correct case, but it appears that it does.

Now, is there a particular reason for not allowing the ICU search ?

Just the same as before — allocation of time and effort. ICU is not a “drop-in replacement” for Boost::regex; it would have significantly delayed me being able to release a public version of this had I included ICU search. Since Notepad++ users are already familiar with Boost::regex syntax, and I am more familiar with its programming interface (and so can work with it more quickly than ICU), I have prioritized Boost::regex.

I am not ruling out adding it later. I will say, though, that I plan to study and attempt to incorporate its useful unique features into Boost::regex before spending too much time trying to implement additional ICU search variants of Search++ functions. It remains to be seen whether I can successfully fork Boost::regex and extend/enhance it to make the ICU search option redundant. It definitely helps me that you are making note of ICU features you miss in Boost::regex.

Regarding the Search++ Results dialog :

Would it be possible to add a Purge option, like in the context menu of the N++ Search results dialog ? You could use the same label Purge for every search or some equivalent ( I do like Purge before each search )

That makes sense and sounds possible. I’ll add it.

Although written in your files list, I also noted that the number of scanned files is not reported in the Search++ Results** dialog, unlike with the N++ **Search results` dialog

And, if possible, it would be best to include the chosen options of the current regex too, like Regex, Case,... ?!

Agreed. I’ll add that information.

To end with, I noticed that, within the N++ Search results, it is possible to easily see all files which has matches, without seeing the matched lines :

By hitting Ctrl and clicking on ⊟, on the first line => The search collapsed after some time and then with a simple click on ⊞

By using the Fold All option of the Context dialog and then a simple click on ⊞ of the first line

I see your point. There is some flexibility missing. I will look for a way to make that easy to do.