Author Topic: New program: FileSearchy - Quick file search utility (freeware) (Read 83,359 times)

Cashper · « **Reply #25 on:** December 18, 2013, 01:38 PM »

Ok, added this to my TO-DO list.

MilesAhead · « **Reply #26 on:** December 24, 2013, 12:46 AM »

I noticed it on http://alternativeto.net/

guess I'll have to try it out.

anandcoral · « **Reply #27 on:** December 24, 2013, 07:53 AM »

Hi Cashper,

Noticed your FileSearchy app today, and I am curious why you did not put it in NANY 2014 instead ?
FileSearchy is freeware, so sets with "NANY" more than "Announce Your Software/Service/Product", I feel.

Well it is your decision, but I am curious.

Regards,

Anand

Cashper · « **Reply #28 on:** December 28, 2013, 02:21 AM »

I haven't put FileSearchy in NANY 2014, because i'm going to create a paid pro version.

sajman99 · « **Reply #29 on:** January 26, 2014, 08:38 PM »

Hi Cashper, I have found FileSearchy (version 1.0) to be an accurate and speedy contents searcher. FWIW here are some questions and comments...

Do you plan to add some type of filtered results (as you did in MultiFind)? I have to agree with the comments of dr_andus that searching many content results is too time-consuming. A filtered/outline view which displays only the searched-for text would enhance the user experience.

So there is currently no hotkey or other expedited method of navigation? This is a real limitation of FileSearchy as it's very cumbersome to click each highlighted line (in the lower pane) to navigate found text. BTW clicking on a highlighted line marker doesn't shift focus to the bottom pane as one might expect.

I also agree with stewcam that folder exclusion should be implemented. For example, I would like to exclude FileSearchy's log file and various temp files.

Also, the context menu integration remains a bit buggy. I have it disabled in options but "Search with FileSearchy" always shows after a few content searches.

IMO there should be a recognition of matches and there should be a column along with found files which enumerates matches in each found file. It would also be very helpful to see a summary of matches and files found/files searched. For example, the summary "103 matches in 20 files of 35 searched" provides significantly more information than FileSearchy 1.0 provides.

Despite these comments about this early version 1.0, I do like FileSearchy and plan to continue using it in advanced mode as a contents searcher.

Cashper · « **Reply #30 on:** January 27, 2014, 06:46 AM »

Hi sajman99,

Thanks for your comments!

Quote

Do you plan to add some type of filtered results (as you did in MultiFind)? I have to agree with the comments of dr_andus that searching many content results is too time-consuming. A filtered/outline view which displays only the searched-for text would enhance the user experience.

So there is currently no hotkey or other expedited method of navigation? This is a real limitation of FileSearchy as it's very cumbersome to click each highlighted line (in the lower pane) to navigate found text. BTW clicking on a highlighted line marker doesn't shift focus to the bottom pane as one might expect.

I was going to implement a navigation bar under a file contents that will show number of matches and "next", "previous" arrows.
But after your post i see that indeed it also makes sense to have a view that contains only matched lines (like in MultiFind).
I will implement this in near future.

Quote

I also agree with stewcam that folder exclusion should be implemented. For example, I would like to exclude FileSearchy's log file and various temp files.

Folder exclusion is in my to-do list. But not a top priority.

Quote

IMO there should be a recognition of matches and there should be a column along with found files which enumerates matches in each found file. It would also be very helpful to see a summary of matches and files found/files searched. For example, the summary "103 matches in 20 files of 35 searched" provides significantly more information than FileSearchy 1.0 provides.

Some summary is already available in status bar: "Found X objects in Y s".
I'm not able to show number of matches in all the found files because when FileSearchy finds the first match in a file is stops and moves to next file. Scanning for all matches is too excessive and will slow down the search.
As for number of searched files, this seems useful, i will consider adding it somewhere.

sajman99 · « **Reply #31 on:** January 27, 2014, 08:26 PM »

Hi Cashper, thanks for responding.

Some type of navigation (if only F3 hotkey) in the content pane would definitely ease the burden of navigating results. I don't have files that are particularly large, but it still quickly gets tedious to click, click, click...just to see the results.

As far as filtered/outline view, my suggestion is that you allow space on both sides of the found text. The only issue I ever had with MultiFind was that the found text was often clipped on the left side (in the Matches tab). So a setting like "allow characters before/after found text" would be very useful.

As to a contents summary, I see the "X objects in X seconds" but was hoping for information about matches. I hadn't realized FileSearchy moves on after the first match because all matches are line-marked and highlighted correctly in the contents pane. BUT if that is the tradeoff (ie. no enumeration of matches) for maintaining the speedy search, then I will gladly choose the speed.

Looking forward to FileSearchy's future!

Cashper · « **Reply #32 on:** February 09, 2014, 01:09 PM »

Hi sajman99,

I think i've implemented what you asked - filtered results for content searches.

[attach=#]

sajman99 · « **Reply #33 on:** February 09, 2014, 09:49 PM »

Hi Cashper, very nice work.

IMO FileSearchy version 1.1 is much improved with a Matches tab displaying filtered results. Concise information at a glance.

BTW is there any quick navigation between the two tabs? IIRC MultiFind could jump from Matches to an exact location in the File tab. Just wondering as that was quite a nice feature.

dr_andus · « **Reply #34 on:** February 09, 2014, 11:36 PM »

Is there a way to rank search results by relevance (e.g. the number of times a search term occurs within a file)?

highend01 · « **Reply #35 on:** February 10, 2014, 06:49 AM »

@Cashper

Does a german translation already exist?

Cashper · « **Reply #36 on:** February 11, 2014, 10:27 PM »

Quote from: sajman99 on February 09, 2014, 09:49 PM

BTW is there any quick navigation between the two tabs? IIRC MultiFind could jump from Matches to an exact location in the File tab. Just wondering as that was quite a nice feature.

I will add this very soon.

Quote from: dr_andus on February 09, 2014, 11:36 PM

Is there a way to rank search results by relevance (e.g. the number of times a search term occurs within a file)?

Not yet.
I think search by relevance and search by number of matches are different things.
Search by a number of matches is not hard to implement, but i don't see a use case that shows when it is needed.
Search by relevance is hard to implement, because i don't have trustworthy criteria to determine relevance.

Quote from: highend01 on February 10, 2014, 06:49 AM

@Cashper

Does a german translation already exist?

No, at the moment.

dr_andus · « **Reply #37 on:** February 11, 2014, 11:25 PM »

Quote from: Cashper on February 11, 2014, 10:27 PM

Search by a number of matches is not hard to implement, but i don't see a use case that shows when it is needed.

To me that is an important basic measure of relevance. The more a search term occurs in a document (especially with some Boolean operator), the more likely that it is relevant. In some applications search results are automatically ranked in such a way, and in most cases the top-ranked search results do turn out to be more relevant ones. Obviously one needs to pick the search terms strategically (I mostly know what the search terms are that are likely to return the results I'm looking for in my collection of documents).

sajman99 · « **Reply #38 on:** February 12, 2014, 10:51 PM »

Quote from: Cashper on January 27, 2014, 06:46 AM

I'm not able to show number of matches in all the found files because when FileSearchy finds the first match in a file is stops and moves to next file. Scanning for all matches is too excessive and will slow down the search.

Cashper, sorry if this is a stupid question, but apparently I'm not understanding what you are saying here. If FileSearchy moves on after the first match, how then does it list every match in each file? I mean, it appears that it is listing everything correctly in both the File tab and the Matches tab (even including line number).

Also, even if you cannot count matches, couldn't you count the lines in the Matches tab? or is it the same problem? For example, there is a well-known program named BareGrep that finds "matching lines". So apparently there can be more than one instance/match in any given line, but the counting is done on a per-line basis.

Anyway, I ask because I agree with dr_andus that counting matches is important. Counting objectively quantifies the findings of the content search. IMO any type of search should attempt to find, display, and quantify findings.

Cashper · « **Reply #39 on:** February 13, 2014, 01:11 AM »

Quote from: dr_andus on February 11, 2014, 11:25 PM

To me that is an important basic measure of relevance. The more a search term occurs in a document (especially with some Boolean operator), the more likely that it is relevant. In some applications search results are automatically ranked in such a way, and in most cases the top-ranked search results do turn out to be more relevant ones. Obviously one needs to pick the search terms strategically (I mostly know what the search terms are that are likely to return the results I'm looking for in my collection of documents).

I will probably add a column with name Matches (or Hits) that will show number of matches in each file. Then you will be able to sort by clicking the column.

Quote from: sajman99 on February 12, 2014, 10:51 PM

Cashper, sorry if this is a stupid question, but apparently I'm not understanding what you are saying here. If FileSearchy moves on after the first match, how then does it list every match in each file? I mean, it appears that it is listing everything correctly in both the File tab and the Matches tab (even including line number).

FileSearchy moves on after the first match, but when you select a file it retrieves all matches for this one file.

Quote from: sajman99 on February 12, 2014, 10:51 PM

Anyway, I ask because I agree with dr_andus that counting matches is important. Counting objectively quantifies the findings of the content search. IMO any type of search should attempt to find, display, and quantify findings.

I hope that adding a new column "fixes" the issue.

Cashper · « **Reply #40 on:** February 13, 2014, 04:26 AM »

Quote from: sajman99 on January 26, 2014, 08:38 PM

Also, the context menu integration remains a bit buggy. I have it disabled in options but "Search with FileSearchy" always shows after a few content searches.

I've tracked down this problem. The next release will have a fix.

sajman99 · « **Reply #41 on:** February 13, 2014, 08:29 PM »

Great news to hear of these fixes and improvements planned for upcoming FileSearchy releases.

Cashper, a couple more questions...

In the event of more than 100 matches in a file, I have noticed that FileSearchy indicates (in The Matches tab) "Only the first 100 matches are shown". Huh...why that limitation? What if there were 500 matches in a file? Then FileSearchy wouldn't show 400 matches in the Matches tab?

I would also like to ask about a "File/Save Parameters" and "File/Open Parameters" feature. This would function to preserve active fields for future searches. Also, it would help to avoid repetitive data entry (of multiple file type/delimiter configs) each time history is cleared. Settings and tabs are saved, so maybe parameters could be also?

Cashper · « **Reply #42 on:** February 15, 2014, 09:44 PM »

Quote from: sajman99 on February 13, 2014, 08:29 PM

In the event of more than 100 matches in a file, I have noticed that FileSearchy indicates (in The Matches tab) "Only the first 100 matches are shown". Huh...why that limitation? What if there were 500 matches in a file? Then FileSearchy wouldn't show 400 matches in the Matches tab?

This limitation is because of slow matches highlighting. In future this will be resolved by either fast highlighting or by additional button to show all matches.

Quote from: sajman99 on February 13, 2014, 08:29 PM

I would also like to ask about a "File/Save Parameters" and "File/Open Parameters" feature. This would function to preserve active fields for future searches. Also, it would help to avoid repetitive data entry (of multiple file type/delimiter configs) each time history is cleared. Settings and tabs are saved, so maybe parameters could be also?

Sound useful and easy to implement. I will add this soon.

sajman99 · « **Reply #43 on:** February 17, 2014, 09:17 PM »

Thanks again, Cashper.

I have experimented a bit and see that any content changes are recognized by FileSearchy very quickly. Dare I say instantaneously!

Since I haven't had any desktop search software installed in a long time, I am curious as to what kind of CPU hit would be expected. Here I am seeing regular 50% CPU usage as FileSearchy reads the USN Journal.

Are other FileSearchy users observing the same or similar CPU usage? Would regular 50% CPU usage be normal and expected?

Cashper · « **Reply #44 on:** February 17, 2014, 09:33 PM »

High CPU usage is a bug, that is fixed in the latest version 1.11.

sajman99 · « **Reply #45 on:** February 17, 2014, 09:57 PM »

Quote from: Cashper on February 17, 2014, 09:33 PM

High CPU usage is a bug, that is fixed in the latest version 1.11.

Hi Cashper. More good news.

CPU seemed high to me, but I figured I would ask. I was going to post in the FileSearchy forum rather than here, but it appears the forum is no more. It seems you fixed the issue before I could post about it.

sajman99 · « **Reply #46 on:** February 24, 2014, 07:07 PM »

OK, I can confirm CPU usage and context menu integration have been fixed.

I like that Advanced mode retains search terms and the last used fields. However, Instant mode takes a different approach -- it remembers nothing. Even if the user moves from Instant to Advanced and then back, search terms are not remembered.

To counter this imbalance, Instant mode needs some options. So how about an option to remember last used search terms? Or remember last X search terms? Or maybe even "Remember last search" (ie. search + results)? These are just ideas -- something to consider.

Also, a Bookmarks function would permit frequently used searches to be performed quickly.

Cashper · « **Reply #47 on:** February 28, 2014, 03:03 PM »

Quote from: sajman99 on February 24, 2014, 07:07 PM

I like that Advanced mode retains search terms and the last used fields. However, Instant mode takes a different approach -- it remembers nothing. Even if the user moves from Instant to Advanced and then back, search terms are not remembered.

Instant mode makes a search with each letter you enter. I don't think it's reasonable to remember instant searches - they are easy to retype.
But i recognize that moving from instant to expanded and back with loosing results is counter intuitive. I will try to come up with a better solution in future.

The latest today's release 1.2 allows to jump from a match to correct position with double click.
Another important change is that content search speed is improved due to using multiple threads.
Pro version now has an ability to search contents of e-books (EPUB, FB2, MOBI).

sajman99 · « **Reply #48 on:** March 01, 2014, 08:52 PM »

Hi Cashper, I have FileSearchy 1.2 and the tab jumping works well. Thanks for adding that function.

Have you considered support for literal operators (AND, OR, NOT) in Instant mode? I had that in mind when asking about history lists, bookmarks, etc. because sometimes the search terms can get rather lengthy when using multiple literal operators.

Cashper · « **Reply #49 on:** May 05, 2014, 09:01 PM »

FileSearchy 1.22 has released.
It includes a function that some of you have asked for: sort by "relevance" (number of matches).
Change list:
- Columns of search results table are now configurable. It is possible to select which columns to show, to change width and position.
- New columns of search results table are available: number of matches, created time, last access time.