Search++: A work in progress

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.

Coises

@guy038 said:

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 )

A question about this. Since it is in a sense a “destructive” option, do you think it should be remembered across Notepad++ sessions, or should it have to be invoked afresh in each session where you want it enabled?

guy038

Hi, @coises,

In my opinion, this option seems more like a way of working than a delete option. So, I think this option should remain active between Notepad++ sessions. Note that it’s presently the case within the N++ Search results panel.

But, of course, on re-opening N++, the N++ Search results and the Search++ Results panels are both cleared silently, before any search !

After opening Notepad+ and a first search, involving the N++ Search results or the Search Results panels, you can easily un-check that Purge option if you plan to compare multiple searches !

BR

guy038

Coises

Search++ version 0.6.1 is available.

This update enhances the Search++ Results list, including adding more detail to the search headers, implementing an “automatically purge” toggle and recognizing single-click in the margin.

All comments, critiques and thoughts are welcome!

@guy038 said:

Would it be possible to add a Purge option, like in the context menu of the N++ Search results dialog ?

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,... ?!

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

This update addresses all those points. See the help for details about the commands in the results list.

I’m not handling folding quite the same way as Notepad++ does. (It could be that in time I will decide to try to emulate Notepad++’s appearance and behavior more closely.) What I did was add a context menu option (also available as Shift+Enter or Shift+double-click) for search header lines that toggles the fold state of all documents in that search without folding the search itself. So if you select Expand/Collapse Search, or double-click, the search folds or unfolds with the folding of documents within it unchanged. If you select Expand/Collapse Documents, or Shift+double-click, when the search is expanded, all documents within that search either expand or collapse (the opposite of whatever is the state of the first document).

I added a few other things, like clicking in a margin being equivalent to double-clicking in a header line or on the first position in a detail line. There is a purge toggle now, and search header lines include information about how many files were searched and the type of search (including modifiers).

guy038

Hello, @coises and All,

Thanks for this quick new version. And many thanks for implementing all propositions that I suggested ;-)) So far, everything seems to work nicely !

Now, one request :

Would it be possible, in the Search++ Results to prevent the displaying of the last character ( an ? sign inside a rectangle ) in all lines ( Search line, Document lines and Matched lines ) ? Personally, I think it globally makes the display harder to read ! Just a personnal appreciation

And one question :

Natively, you can swap the keyboard focus between the N++ Search results and the Current document window by hitting the F7 key. I do not see an equivalent with your Search++ plugin

I mean :

When, both, the Search++ and the Search++ Results panels are opened, you can swap the keyboard focus between them with the Ctrl + H shortcut. How to toogle between the Search++ Results and the Current document window ?

Best Regards,

guy038

guy038

Hi, @coises and All,

Sorry, but I came across a serious bug regarding the ICU search, since Search++ version v0.6

The Find in Selection, Find in Marked Text and Find in Whole Document options
The Find All in Selection, Find All in Marked Text and Find All in Whole Document options

Triggers the closure of Notepad++, without saving any configuration file and unsaved tabs

After some quick tests :

The Select, Mark and Show options,
The Count in Selection, Count in Marked Text and Count in Whole Document

Seems to work correctly in ICU mode

BR

guy038

Coises

@guy038 said:
I came across a serious bug regarding the ICU search, since Search++ version v0.6

Thank you for the detailed report. I can reproduce it… in the release version. It doesn’t happen in a debug version (which uses exactly the same code); so it’s a subtle error somewhere. I will find it.

I changed some existing code when I added Find in Files. You observation that this fault began in 0.6 will help me know where to look.

Coises

@guy038 said:

Would it be possible, in the Search++ Results to prevent the displaying of the last character ( an ? sign inside a rectangle ) in all lines ( Search line, Document lines and Matched lines ) ?

Huh. I know what must be causing that, but I don’t know why it is causing it (on your system, but not on mine). (I set line ending characters to be displayed, but then to display with zero opacity. I do this so the marks I place to indicate a zero-length match will still show when the match occurs at the end of a line. The mark must be placed on the following character, and if the character isn’t shown, neither is the mark.)

Would you tell me what font you use for Notepad++ documents (the Search++ Results window copies that from the document window) and what you have at Settings | Preferences… | MISC. for rendering mode (GDI or DirectWrite)?

If I can figure out why you see the characters, hopefully I can figure out what to change so that you (and others with the same configuration) won’t see them.

Natively, you can swap the keyboard focus between the N++ Search results and the Current document window by hitting the F7 key. I do not see an equivalent with your Search++ plugin

The problem is that Search++ can’t (or shouldn’t… see below) control what shortcut keys do when focus is in Notepad++.

From the Search++ Results window, Ctrl+N will take you to the document. To switch from the document to the Results, though, I’d have to add a Search++ Results entry on the Plugins | Search++ menu, and then you’d have to set a shortcut for that in the Notepad++ shortcut mapper. You probably wouldn’t want to give up Ctrl+N, though.

The only way to get from Notepad++ to Search++ (or any plugin) is through a shortcut that’s either manually added in Shortcut Mapper or added by default in the plugin’s setup. (I’m still not sure how conflicts are resolved when a plugin defines a shortcut key that is already defined by default, by the user or by another plugin. I did define a few shortcut keys in Columns++ for manipulating rectangular selections, but it still bothers me that it feels a little… arrogant… to do that. My plugin might not be as important to the user as something else that also wants those keys.)

I am open to suggestions on how to manage this. I agree that consistency between navigation keys used when focus is in the plugin and when focus is in Notepad++ would be desirable, I just don’t have a plausible design for it.

guy038

Hi, @coises,

Practically, I installed your plugin Search++ on a 8.9_x64 version of N++

As you can see, in the screenshot below :

I did not hit the Show All characters option ( ¶ )
I did a search on a specific folder ( ^Music )
Most of the time, I use the Consolas font ( Consolas / Version 7.00 / Disposition **Open Type** signé numériquement **True Type Contours )

But you found out the culprit : it’s just because the GDI ( most compatible) option was selected !. Luckily, for any other option of the rendering mode, after closing an re-starting N++, this special character does not display, anymore !

Regarding the problem about swapping between the Search++ Results and the Current Document window, do not bother about it :-))

May be, you remenber that I personally used the Ctrl + Shift+ N shortcut to open the Search... option. Thus, each use of the Ctrl + Shift + N, alternatively, opens or closes my Search... docked panel

So, I was able to deduce a way ( rather long, of course ) to do that :

Firstly, use Ctrl + N shortcut to switch to the Current Document window
Secondly, use the Ctrl + Shift + N shortcut to put the focus on the Search.. panel
Thirdly, use the Ctrl + H shortcut to get the focus on the Search++ Results panel, again !

Even, on my French keyboard, the H key is quite close to the N key !

BR

guy038

Coises

@guy038 said:

But you found out the culprit : it’s just because the GDI ( most compatible) option was selected !. Luckily, for any other option of the rendering mode, after closing an re-starting N++, this special character does not display, anymore !

Thanks for documenting that!

It should appear correctly in GDI mode too, of course. I suspect the problem will turn out to be that GDI mode doesn’t support alpha transparency, so my setting the opacity to zero is doing nothing. I’ll have to find another way.

Coises

Search++ version 0.6.2 is available:

Fix a critical error that caused ICU searches to crash Notepad++.
Fix unwanted characters appearing at the ends of lines in the Results list with Notepad++ rendering mode GDI.
Fix regression of line ending symbols being in text color instead of white space color, and switch the CRLF symbol in GDI mode to one that hopefully renders more consistently.

Thanks to @guy038 for catching the ICU error and the unwanted characters in the results list in GDI mode.

(The ICU error appears to have been due to an uninitialized variable. The faulty code has been there from the beginning. As chance would have it, up until now it just happened to land on memory that contained an innocuous value. Hopefully I didn’t miss anything else similar…)