Search++: A work in progress

guy038

Hi, @coises and All,

@coises, I read carefully your last two posts and many thanks for all your explanations !

Regarding your point #3 :

You said :

I’m questioning the sense of that now. I’m thinking that if the user specifies “in selection” or ”in marked text,” and there is none, the search should fail with a message like “No marked text to search”

Indeed, it quite disturbing for example that, when no selection and no marked text exists, the Count in selection or Count in Marked Text options still return all the matches of current document ! Give it a try, searching for the insensitive word fix within the last change.log file ( You should get 32 matches ! )

So I support your idea that, in this specific case, the search should fail with the message No marked text to search or No selection to search

Regarding your point #1 :

I totally understand your logic. This make sense !

Regarding your point #2

You began with :

Mark commands that don’t specify a scope …

Are we agree that you’re speaking about the Mark Before and Mark after options ONLY ? Presently, as you said, these two commands, not restricted to a scope, search throughout all file contents.

Now, as expressed in your very last post, I do support your idea to avoid any command, containing Before or After, that do not include a scope ( in Selection, in marked Text and in Whole Document ). Thus, that should solve automatically this problem ;-))

One question :

Let’s suppose the v8.9.3 change.log in a tab
Now, enter the regex (?si) 1.+?(?=^\R) in the Search dialog
Click on the ▼, after the defeautl Find All option
Run the Mark > Mark in Whole Document option

=> Message : Marked 4 matches

Now, with the (?si) 1.+?(?=^\R) regex still present in the Find dialog
Run the Mark > Mark in Marked Text option

=> We get the message No matches found in marked text. Is this coherent, @coises ?. To my mind, I was expecting the message 4 matches in marked text !

Of course, I know that, normally, I should have changed the search, in between ! For example :

Write the (?i)fix regex, in the Find dialog
Run again the Mark > Mark in Marked Text option

=> The fix word, whatever its case, is now marked, from all the previous marked regions, ONLY !

You’ll note that the fix string within all the lines beginning with Notepad++, which were not concerned by the previous search, are not marked, as expected !

Regarding the Remove marks from all open documents and Remove marks from documents in this view options, in the Tools dialog :

Could you move them to an other place of the Tools dialog, in order to not be close to the Remove marks from active document option, that we’ll probably use more often ?

OR :

Could you add a confirmation dialog for these two specific options ?

Best regards

guy038

Coises

@guy038 said in Search++: A work in progress:

Regarding your point #2

You began with :

Mark commands that don’t specify a scope …

Are we agree that you’re speaking about the Mark Before and Mark after options ONLY ? Presently, as you said, these two commands, not restricted to a scope, search throughout all file contents.

It applies to the plain Mark command, too. If there is a non-empty selection (that’s “large enough” per Settings), Mark will perform Mark in Selection (not possible for Mark Before and Mark After). But none of the three will perform Mark […] in Marked Text; that has to be selected explicitly. The same isn’t true for Select; if there is an existing selection (large enough), Select will perform Select in selection. What I was thinking is that perhaps this difference between Mark and Select should be “explained” by having an additional setting for each action, enabled only when Automatically search within {selections | marked text} is checked, that controls whether the matching command is an exception (that is, Select doesn’t perform Selection in Selection, or Mark doesn’t perform Mark in Marked Text). The current behavior would have the “except Select” box unchecked and the “except Mark” box checked.

It comes down to: What do you want to do when you say Select and there’s already a selection, or you say Mark and there’s already marked text? Do you replace the existing selection or marks? add to them? or search within them?

And when I put it that way… I have to think this through some more. From a user’s perspective, the Settings I have are too difficult to figure out. I’m having trouble getting a clear picture of what settings make sense with what other settings and I wrote the damn thing. :-(

Now, as expressed in your very last post, I do support your idea to avoid any command, containing Before or After, that do not include a scope ( in Selection, in marked Text and in Whole Document ). Thus, that should solve automatically this problem ;-))

It would get rid of some of the problem, but not all of it. Where I’m stuck is that I really want there to be “adaptive” commands (the plain Count, Find All, etc.) that recognize when the user would want to search in a selection or in marked text, so they can be the one-click action on a button. Alas, there’s that fundamental design flaw in all computers thus far produced: the RUM (“read user’s mind”) instruction was never implemented. It could be that making an appropriate guess is hopeless. But I really don’t want an oversized, cluttered interface with a matrix of 20 buttons, and I really don’t want users to have to select operations they use often or repeatedly from button menus. So, at least for a while, I’m going to keep trying.

I appreciate your feedback on these issues very much. Anything you, or anyone, can tell me about what works smoothly and what is difficult to use or doesn’t work as expected is helpful.

Now, enter the regex (?si) 1.+?(?=^\R) in the Search dialog

Click on the ▼, after the defeautl Find All option

Run the Mark > Mark in Whole Document option

=> Message : Marked 4 matches

Now, with the (?si) 1.+?(?=^\R) regex still present in the Find dialog

Run the Mark > Mark in Marked Text option

=> We get the message No matches found in marked text. Is this coherent, @coises ?. To my mind, I was expecting the message 4 matches in marked text !

I did document this, but it’s easily missed:

For a regular expression search, each run of marked text is searched independently; the search in any span of marked text cannot “see” outside that span. This affects the behavior of assertions (including word boundaries, lookaheads and lookbehinds, ^ and $).

The search in Columns++ has the same limitation. I couldn’t figure out a practical way to make it work other than this way.

Regarding the Remove marks from all open documents and Remove marks from documents in this view options, in the Tools dialog :

Could you move them to an other place of the Tools dialog, in order to not be close to the Remove marks from active document option, that we’ll probably use more often ?

OR :

Could you add a confirmation dialog for these two specific options ?

I will work out something so they won’t be easily clicked by accident.

guy038

Hi, @coises and All,

Oh… My God ! I forgot about the Find All, Select, Mark and Show options, which do not have any scope, too !

So, in summary :

Regarding the scope :
- If this icon appears, before the button label, the Default scope will be used
- if this icon appears, before the button label, the Whole Document scope will be used
- if this icon appears, before the button label, the in Selection scope will be used
- If this icon appears, before the button label, the in Marked Text sope will be used
Regarding the extent :
- If this icon appears, after the button label, the Forward extent will be used
- If this icon appears, after the button label, the Backward extent will be used
- If this icon appears, after the button label, the Before extent will be used
- If this icon appears, after the button label, the After extent will be used
- If this icon appears, after the button label, the Any extent will be used
- If this icon appears, after the button label, the All Docs extent will be used
- If thisi con appears, after the button label, the Current View extent will be used

Regarding your question :

What do you want to do when you say Select and there’s already a selection, or you say Mark and there’s already marked text? Do you replace the existing selection or marks? add to them? or search within them?

To my mind, I would say :

Regarding Marked text
- Add current marked text region(s) to existing one(s) and operate within the union of all these searched regions as Search++ does presently. If we don’t want to keep previous marked region(s), we can simply use one of the three Tools > Remove Marks from... options, first

Regarding selections :
That’s not the same story ! Indeed, for any command that does not delete the current selection(s), like Count in Selection, Find All in Selection , Select in Selection, Mark in Selection, Show in Selection, and Replace All in Selection : no problem. Thus :
- Add current selection(s) to existing one(s) and operate within the union of all these selections as Search++ does presently. If we don’t want to keep previous selection(s), we can simply put the caret anywhere in current document, first

Note this tip regarding the Show command : after running your first Show in Selection option, you can use the Tools > Show all Lines option, to display all the document again, and then, add new selection(s) and, finally, run again the Show in Selection option !

Now, for any command that cancels all previous selection(s), like the Find in Selection option, the Replace and Find in Selection option and the Find or Replace in Selection option, they seem to act on the whole document, anyway !

Strictly speaking, to handle properly this case, you should keep a map of the beginning and end of EACH selection, in current document ! Probably not easy with huge documents and a nightmare because of all possible types of selection :-((

It’s worth noting that, within Notepad++, the In selection possibilities are restricted to these 5 actions, ONLY :

The Count action
The Find All in current Document action
The Replace All action
The Mark All action
The Clear all marks action

BTW, why the choice between the Replace and Find... options and the Find or Replace... options is not placed in the Settings dialog, like within Notepad++ ? This would simplify some menus !

I understand, now, why the Mark in Whole document option returns 4 matches and the Mark in Marked Text option returns No matches found in marked text. Once any marked text exists, that means that any other operation will consider this marked text ONLY

Thus, as current document is the last change.log file and the current regex in Find dialog is (?si) 1.+?(?=^\R), the total amount of marked text is, indeed, the text below :

 1. Regression fix: a crash in User Defined Language.
 2. Regression fix: installing (or removing) plugin re-opens Notepad++ with permanent admin privilege.
 3. Regression-fix: wrongly added parenthesis for some multi-bytes characters.
 4. Regression-fix: incorrect function list text display for non-UTF8 documents.
 5. Regression-fix: ProjectPanel Workspace text localization issue.
 6. Regression-fix: Change History margin not enabled by default.
 7. Regression-fix: Notepad++ update & plugin download fail behind corporate MITM proxies.
 8. Security enhancement: Update cURL to v8.19.0 in auto-updater (WinGUp) to fix cURL security issue (CVE-2025-14819).
 9. Improve performance by migrating the XML parser from TinyXML to pugixml.
10. Update Scintilla to 5.6.0 & Lexilla to 5.4.7.
11. Fix the issue where printing caused Notepad++ to crash.
12. Fix Find in Files failing to search file content on disk.
13. Add disableNppAutoUpdate.xml to disable auto-update when WinGUp (GUP.exe) is present.
14. Fix a memory leak on exit.
15. Fix installed auto-completion files not overwritten after update.
16. Add model capacity of shortcuts.xml & contexMenu.xml for administration.
17. Add an option to disable selected text drag-and-drop.
18. Fix wrong theme-writing path for non-ProgramFiles installations.
19. Enhancement: prevent XML config files from being overwritten when updating portable package (copy/paste).
20. Fix incomplete Find dialg tab translation when 1st opêned from Project Panels.
21. Fix Notepad++ spawning a new Windows Explorer process in Task Manager.
22. Add Function List & Autocompletion for D language.
 1. Security enhancement: Make updater check interity & authenticity of server-returned XML (XMLDsig).
 2. Security enhancement: Fix untrusted search path vulnerability (CVE-2026-25926) by launching explorer.exe.
 3. Security enhancement: Make auto-updater (WinGUp) even more secured (Remove dll dependency & unscured options).
 4. Fix a plugin installation crash due to incorrect processing catch.
 5. Add redact selection feature - Default: █, Modifier (Shift + Click): ●.
 6. Fix context menu shortcut localization not aligning to the right regression.
 1. Fix EOL duplication regression when playing back old recorded macros.
 2. Remedy search failure for pasted text containing trailing invisible EOL character.
 3. Fix customized context menu regression where separator (id="0") escapes FolderName submenu.
 4. Fix issue where a single undo reverted multiple changes after macro execution.
 5. Fix visual glitch when dragging dockable dialogs on a 2nd monitor.
 6. Fix inconsistent automatic search mode switching (RegEx to Extended) in Find dialog.
 7. Fix incorrect URL parsing caused by Unicode special spaces.
 8. Update to Boost 1.90.0.
 9. Improve update themes feature: fix JavaScript.js edge case.
10. Update javascript.js to better match javascript (embedded) in all themes.
11. Function List: enhance for Perl & PHP; add for Nim.
12. Fix comments and highlighting in TCL.
13. Update perl keywords and autocomplete for 5.42.
14. Improvement: display Find dialog status message with invisible characters warning.
 1.  NppExport v0.4
 2.  Converter v4.7
 3.  Mime Tool v3.1

And it’s easy to verify that the regex cannot produce any match as no empty line exists ( the look-ahead (?=^\R) ), in this text, to limit the search scope !

Now, @coises, we can trick your plugin by modifying the regex to search !! Here’s how, just for fun :

First, use the Tools > Remove marks from active document
Type in the regex (?si) 1.+?(?=^\R)|(?<=[.1]\r\n)\R in the Find dialog

You’ll note that , this time, we also search for any line-break if prececed with .\r\n or 1\r\n

Click on the ▼ of the Find All button
Choose the Mark option

=> Message Marked 8 matches ( So the previous 4 zones of text and the 4 line-breaks )

Now, change the present regex, in the Find dialog, by the regex (?si) 1.+?(?=^\R)
Click on the ▼ of the Count button
Run the Count in Marked Text option. Bingo : we do get the message 4 matches in marked text

-And, if we use the default Find button, it does matches, succcessivly, 4 bunches of text ;-))

Best Regards,

guy038

Coises

@guy038 said in Search++: A work in progress:

Now, for any command that cancels all previous selection(s), like the Find in Selection option, the Replace and Find in Selection option and the Find or Replace in Selection option, they seem to act on the whole document, anyway !

Not quite (unless there’s a bug). The first match (meaning first in time) will be the first match (meaning top/left) in the selection for a forward find, or the last match in the selection for a backward find.

After that, the selection is lost. However:

Strictly speaking, to handle properly this case, you should keep a map of the beginning and end of EACH selection, in current document ! Probably not easy with huge documents and a nightmare because of all possible types of selection :-((

That came up in the discussion @Alan-Kilborn and I had when I was working out search in Columns++. Later in that discussion, Alan mentioned the idea of marking text, which became the basis for how search in Columns++ works.

In Search++, there is an option is in the Settings dialog: Convert selections to marked text before beginning a stepwise search. This applies only when you use a stepwise command without a scope specified (default scope); so, if that option is checked, Find when there is a selection (but no marked text) will convert the selection to marked text and search within the marked text, but Find in Selection won’t.

BTW, why the choice between the Replace and Find... options and the Find or Replace... options is not placed in the Settings dialog, like within Notepad++ ? This would simplify some menus !

My thought was that users might change their mind about whether they want to see what the replacement did before moving on; for example, with a complicated regex replacement, perhaps at first wanting to see each replacement in context, then if they seem to be working as expected, start skipping forward to the next candidate for replacement.

guy038

Hello, @coises,

For the last time this season, I went skiing with two friends, just three hours, because the snow conditions started to deteriorate in the afternoon. Our previous outing, last week, was great because it was much colder that day !

Let’s back on topic ;-))

You said :

Not quite (unless there’s a bug). The first match (meaning first in time) will be the first match (meaning top/left) in the selection for a forward find, or the last match in the selection for a backward find.

After that, the selection is lost. However:

So, I agree with you that the very first match is correct and expected, but all the subsequent ones are not !

But, luckily, you add :

In Search++, there is an option is in the Settings dialog: Convert selections to marked text before beginning a stepwise search. This applies only when you use a stepwise command without a scope specified (default scope); so, if that option is checked, Find when there is a selection (but no marked text) will convert the selection to marked text and search within the marked text, but Find in Selection won’t.

Ah… very instructive, indeed. So, we have a mean to look within selections ONLY, if we check the Convert selections to marked text before beginning a stepwise search, in the Settings dialog. It will automatically cancel the selection(s) and replace them with some equivalent Marked text regions. I tested that feature : nice !

Regarding the choice between the two options Replace and Find and Find or Replace :

You said :

My thought was that users might change their mind about whether they want to see what the replacement did before moving on; for example, with a complicated regex replacement, perhaps at first wanting to see each replacement in context, then if they seem to be working as expected, start skipping forward to the next candidate for replacement.

I do understand your point of view ! Now, I’m thinking about an other solution :

In settings, you would create a new option :

How many times you want to [ immediately ] check the result of replacements, with the possible values :

Never
Always
A digit from 1 to 9

So :

In case of the Never answer, the usual Find And Replace would be used
In case of the Always answer, it would be like when the Replace : Don't move to the following occurrence option is checked, in Settings > Preferences > Searching of native N++
In case of a digit answer, between 1 to 9, the first replacements would act as the Find or Replace options of Search++ and all the next replacements would act as the Replace and Find options of Search++

And, to my mind, a default value of 3 would be appropriate !

Best Regards,

guy038

Coises

Search++ version 0.5.2 addresses a number of issues:

Fix display of Settings: Mark style drop-down in dark mode. (@Snabel42: this should fix the problem you described here.)
Add a dialog to resist accidentally clicking the Tools menu options to remove marks from documents in view or from all open documents. (per @guy038, last point here)
Rearrange Settings dialog and add four new settings:
- Fill after Search… menu command or shortcut even if search dialog is already visible.
- Allow default Select command to Select in Selection.
- When eligible selection and marks are present, default search is within selection.
- Allow default Mark command to Mark in Marked Text.
Make commands that explicitly specify in Selection or in Marked Text show a failure message (rather than fall back to in Whole Document) if there is no selection or marked text.
Remove Before and After commands without an explicit scope from command button menus.
Apply the action Convert selections to marked text when beginning a default stepwise search only when the search finds a match.
Change names of stepwise replace commands to Replace (then find) and Replace (then wait).
Fix adding to selection not working when the selection is a rectangular selection. Add note to help regarding unexpected results when adding to existing selections.
Update and clarify documentation, particularly the Search commands and Settings sections.

Thanks to everyone who has contributed to this discussion so far! Search++ still has a lot of rough spots and omissions, but it’s getting better.

Vitalii Dovgan

@Coises
Thank you for the update!
My next suggestion may ruin one of the initial purposes of Search++, but maybe you’ll find it useful anyway? Here it is: the “icudt78.dll” is a big DLL with a size of 32 MB, and when I think about a portable version of Notepad++, I usually consider a portable and small version of Notepad++. Correspondingly, what do you think about an attempt to load the “icudt78.dll” at runtime and if it is not available then just disable the “ICU” button and allow the rest of the plugin to operate normally?

Coises

@Vitalii-Dovgan said in Search++: A work in progress:

My next suggestion may ruin one of the initial purposes of Search++, but maybe you’ll find it useful anyway? Here it is: the “icudt78.dll” is a big DLL with a size of 32 MB, and when I think about a portable version of Notepad++, I usually consider a portable and small version of Notepad++. Correspondingly, what do you think about an attempt to load the “icudt78.dll” at runtime and if it is not available then just disable the “ICU” button and allow the rest of the plugin to operate normally?

Regex search also depends on ICU, so I can’t really make it optional.

One of the major “under the hood” changes I made when I built Search++ based on the search in Columns++ was to use ICU for all the Unicode properties instead of the rather hacked-together approach I used in Columns++. The underlying engine in both search in Columns++ and Regex search in Search++ is Boost.Regex, with a considerable amount of customization to make it work well with Scintilla and with Unicode.

I’m really hesitant to reverse that, as the ICU properties are more accurate and easier to update when Unicode releases new versions, while the Columns++ approach is tricky and a bit fragile, and still doesn’t get everything right.

However, as you note, it does increase the size: that one dll is over six times the size of the plugin dll. It also appears that the current version of the ICU4C dll files (at least the pre-compiled ones) don’t work on Windows 7 (and presumably Windows 8).

So… I suppose it’s possible that at some point I’ll try to undo the use of ICU and go back to the cobbled-together approach, but this time get it right. I can’t hold out hope that it will happen soon, nor promise that it will happen at all.

Edit to add:

I included the ICU search mostly for testing. ICU’s native search doesn’t integrate well with Scintilla, and it lacks some of the syntax familiar to Notepad++ users from Boost.Regex. Since I haven’t manipulated its search process at all, results from ICU searches can serve as a check on whether Regex is properly implemented (allowing for expected/intentional differences). I might remove it before Search++ comes out of pre-release status; but @guy038 has expressed hope that I will leave it in, so it will probably remain, perhaps hidden in some way.

Snabel42

@Coises said in Search++: A work in progress:

Search++ version 0.5.2 addresses a number of issues:

Fix display of Settings: Mark style drop-down in dark mode. (@Snabel42: this should fix the problem you described here.)

It does indeed, thank you!

guy038

Hi,@coises and All,

I’m exploring all the possibilities when you click on the ICU button and, really, you access a new regex world with a lot of new options, all related to UNICODE !

In addition, you get some new regex syntaxes which are easier to interpret and allow an almost infinite number of ways to define an Unicode range of characters !

For example, if we’re searching ,with the Match case option checked, in my Total_Chars.txt file :

The search [[\p{letter}][\p{number}]] is the UNION of the [\p{letter}] and the [\p{Number}] properties. Thus, it returns 145,672 matches OR 1,924 matches = 147,596 matches. It could simply be replaced by the Boost syntax [\p{letter}]|[\p{number}].
The search of [[:letter:]&&[\p{InArabic}]] is the INTERSECTION of the [:letter:] and the \[\p{InArabic}]] properties. Thus, it returns 153 matches which is the amount of letter characters in the main Arabic block. It could be replaced by the Boost syntax (?=[[:letter:]])\p{InArabic}. It returns 145,672 AND 256 = 153 letters within this main Arabic block.
The search of [[:letter:]--[a-z]] is the ASYMETRIC DIFFERENCE between the [[:letter:]] and [a-z] properties = 145,672 - 26 which returns 145,646 characters. It could be replaced by the Boost syntax (?![a-z])[[:letter:]] which also returns 145,646 chars.

I’m still looking for all the ICU properties returning a valid value, against my Total_Chars.txt file ! Be patient some days as it remains about 600 properties not tested !!

Best Regards,

guy038

BTW, @coises, what do you think of my idea regarding the two options, Replace (then find) and Replace (then wait) ?

Coises

@guy038 said in Search++: A work in progress:

I’m still looking for all the ICU properties returning a valid value, against my Total_Chars.txt file ! Be patient some days as it remains about 600 properties not tested !!

I would expect that they will all work. I have avoided tampering with the ICU search, so it can serve as a reference standard for the Regex search as far as Unicode properties.

There are some Boost.Regex constructs that ICU does not support. The ones I know about right now are backtracking control (like (*SKIP)(*FAIL)); \K; and \l and \u as shorthand for [[:lower:]] and [[:upper:]]; there may be others. I don’t expect that I will attempt to modify the ICU syntax in any way.

Offering ICU as a “first class” search (working on documents that aren’t UTF-8, being able to replace as well as find, being reasonably efficient for large documents, etc.) is probably possible, but it will take a lot of work. I’m not at all certain it is a task I will attempt.

On the other hand, once the framework is in place and I feel comfortable taking Search++ out of pre-release status, I do hope to add more of the ICU properties to regular Regex.

BTW, @coises, what do you think of my idea regarding the two options, Replace (then find) and Replace (then wait) ?

I see your point that the Replace drop-down has become overwhelming with all the options, especially in Plain search.

I’m now planning to add a toggle item (with a check mark) to the Tools menu; something like Jump to next match after Replace. I’m also planning to add keyboard shortcuts for (most or all of) the Tools menu items. That would make it reasonably easy to toggle between Replace (then find) and Replace (then wait) without complicating the menu so badly. (With the shortcut it would be more keyboard-friendly than the present arrangement.) The next version will include something like that, unless I encounter an unexpected obstacle or think of a better idea.