Page 1 of 1

Search results request

Posted: 14 Sep 2009 21:51
by diarrhio
I use XY as my tool to grep w/in files and I am quite happy with it's speed and feature set.

However, it is missing something which other search tools have.... the ability to view "inside" the file to see the match. You often want to know what the match is in addition to knowing the fact that there was a match. Visual Studio's search in files has this feature, as a reference, as does Windows Greg and Agent Ransack, to name a few.

I'm not sure how to best implement this in XY. I imagine there are 3 choices:
  1. A sub-pane of the search results tab. When you clicked on one of the results, the sub-pane would show the contents of the file, scrolled to the line where the match was found.
  2. Similar to the above, but instead of a sub-pane, just use the Preview or Raw View tabs in the Info Panel
  3. A column in the search results which has a text fragment of the matching line. This would be the least desirable option since you could only show one line of results
I imagine the second one (using the Preview or Raw View tab) would be easiest to implement since all you would have to do is add a line number to scroll to.

What do you think?

Re: Search results request

Posted: 14 Sep 2009 21:56
by admin
I see the need of it. However, I don't see a good way to do it.

"A sub-pane of the search results tab." -- what do mean by this?

Re: Search results request

Posted: 14 Sep 2009 22:05
by diarrhio
Take the existing Search results tab and split it into two sections, using a splitter... the top will be the current search results... the bottom will be a file viewer, which will show the contents of the selected file in the search results.

Basically, you just need a text viewer somewhere and the ability to scroll to a line inside the file (since you will only save the line number of the first match). The question is, where do you put this text viewer? I like the suggestion of using the Preview or Raw View tab since those are already text viewers and all you need to add is the ability to scroll to a line. i.e. you wouldn't have to add any new UI... all you need to do is save a line number with each search result. Then, if the user has the Preview or Raw View tab open, instead of just showing that file starting at the top, show the file and scroll to the matching line number. That only requires you to two things to XY (store the line number with search result and scroll to a line number in the existing text viewer(s) ).

Make sense?

Re: Search results request

Posted: 14 Sep 2009 22:07
by admin
diarrhio wrote:Take the existing Search results tab and split it into two sections, using a splitter... the top will be the current search results... the bottom will be a file viewer, which will show the contents of the selected file in the search results.

Basically, you just need a text viewer somewhere and the ability to scroll to a line inside the file (since you will only save the line number of the first match). The question is, where do you put this text viewer? I like the suggestion of using the Preview or Raw View tab since those are already text viewers and all you need to add is the ability to scroll to a line. i.e. you wouldn't have to add any new UI... all you need to do is save a line number with each search result. Then, if the user has the Preview or Raw View tab open, instead of just showing that file starting at the top, show the file and scroll to the matching line number. That only requires you to two things to XY (store the line number with search result and scroll to a line number in the existing text viewer(s) ).

Make sense?
Yes, but unlikely my choice. I'm afraid I won't come back to this before the current roadmap is done.

Re: Search results request

Posted: 14 Sep 2009 22:14
by diarrhio
OK. Do you have a link to your roadmap? Also, how would you envision doing it and what is wrong (out of curiousity) with the given suggestions?

Re: Search results request

Posted: 14 Sep 2009 22:20
by admin
diarrhio wrote:OK. Do you have a link to your roadmap? Also, how would you envision doing it and what is wrong (out of curiousity) with the given suggestions?
No, I didn't say it's wrong. It just looks like something I cannot squeeze in.

roadmap: http://www.xyplorer.com/xyfc/viewtopic.php?f=10&t=830

Re: Search results request

Posted: 14 Sep 2009 22:30
by diarrhio
admin wrote:No, I didn't say it's wrong. It just looks like something I cannot squeeze in.
Got it, thanks. I always seem to mis-understand you... don't know why that is.

Re: Search results request

Posted: 15 Sep 2009 17:22
by j_c_hallgren
diarrhio wrote:I like the suggestion of using the Preview or Raw View tab since those are already text viewers and all you need to add is the ability to scroll to a line. i.e. you wouldn't have to add any new UI... all you need to do is save a line number with each search result.
Instead of a line nbr, I'd think using what I know as "RBA" (Relative Byte Addr) would be easier as line nbrs may not be applicable in all cases...in any case, knowing/seeing where the match occurs could be very helpful as you may thus not need to open the file and redo the search to locate it in context, as the data you may want may not be the actual search values but something related to it...like email address tied to a pnone nbr, for ex.

Re: Search results request

Posted: 15 Sep 2009 19:24
by admin
j_c_hallgren wrote:
diarrhio wrote:I like the suggestion of using the Preview or Raw View tab since those are already text viewers and all you need to add is the ability to scroll to a line. i.e. you wouldn't have to add any new UI... all you need to do is save a line number with each search result.
Instead of a line nbr, I'd think using what I know as "RBA" (Relative Byte Addr) would be easier as line nbrs may not be applicable in all cases...in any case, knowing/seeing where the match occurs could be very helpful as you may thus not need to open the file and redo the search to locate it in context, as the data you may want may not be the actual search values but something related to it...like email address tied to a pnone nbr, for ex.
I just had an idea that could work: Have a list right on the Contents tab (at the right side of the text box) that will list all matches (with surrounding text) of the current Contents entry in the selected and focused file WHEN the tab is open and a file gets selected. Even in the normal file list! (= browse mode: No file find necessary but possible!) Even me I could use that... :)

Re: Search results request

Posted: 15 Sep 2009 20:42
by j_c_hallgren
Yea! Sounds like a promising idea! Given that I've never used much of that box, so reducing its width (like split in 1/2 or so?) to make room for a results area would be fine with me...

The thing I'd still want to see is some sort of a position in file, and if text type file, ideally a line nbr, but at least a hex offset with each string...the amount of surrounding text (nbr bytes) may need to be user defined via obscure method as some may want 15 chars and other s may do with 5.

Here's another twist: When looking at the Contents tab, and using "wide IP", there is a heck of a lot of gray area at the right side that could be possibly used for this purpose maybe?...actually, within Find Files on other tabs in narrow IP mode, there is a fair amout of gray space there...squeezing some of these tabs to the left to allow results room at right side may be something to look at IF it's possible.

Maybe I've totally missed something obvious but trying to come up with some thoughts..

Re: Search results request

Posted: 15 Sep 2009 20:47
by admin
j_c_hallgren wrote:Yea! Sounds like a promising idea! Given that I've never used much of that box, so reducing its width (like split in 1/2 or so?) to make room for a results area would be fine with me...

The thing I'd still want to see is some sort of a position in file, and if text type file, ideally a line nbr, but at least a hex offset with each string...the amount of surrounding text (nbr bytes) may need to be user defined via obscure method as some may want 15 chars and other s may do with 5.

Here's another twist: When looking at the Contents tab, and using "wide IP", there is a heck of a lot of gray area at the right side that could be possibly used for this purpose maybe?...actually, within Find Files on other tabs in narrow IP mode, there is a fair amout of gray space there...squeezing some of these tabs to the left to allow results room at right side may be something to look at IF it's possible.

Maybe I've totally missed something obvious but trying to come up with some thoughts..
Yes, there's no hurry with this. We'll see...

Re: Search results request

Posted: 23 Jan 2010 16:20
by SkyFrontier
EDIT: Improved code (a bit):

Code: Select all

::copytext ("<curpath>\"); status "Paste current path (CTRL+V) into Finder!"; open "<xydata>\_RES\Soft\Finder\Finder.exe"
admin:
I just had an idea that could work: Have a list right on the Contents tab (at the right side of the text box) that will list all matches (with surrounding text) of the current Contents entry in the selected and focused file WHEN the tab is open and a file gets selected. Even in the normal file list! (= browse mode: No file find necessary but possible!) Even me I could use that... :)

-PowerDesk File Finder is a good tool (the best I ever seen!) to achieve that results. Currently I am using it combined with a script to launch Finder, copy current location to clipboard and get it ready to be used in Finder's Path field, which is not updated when launched from inside XYplorer!
I am looking for a Pro version 5, if anyone has a link to it, please post it here. The FREE version 5 comes with Finder v. 5, which has small improvements over v. 4 (namely a Files Types field that v. 4 hasn't, as far as I can recall), which is probably the one that is still available in a few sites.

Code: Select all

copytext ("<curpath>\"); status "Paste current path (CTRL+V) into Finder!"; open ".\_Res\Soft\Finder\Finder.exe"
The best feature it has over concurrency: it shows exactly what you want, each time it occurs, plus a few "context entries".
The worst feature it has: it shows exactly what you want, each time it occurs. When encountering a large set of occurrences, mostly entries that belongs to a folder whose name matches the query, it will show ALL of the folders that contain the searched term.

So in a search for "Wilbur", meaning "wilbur.jpg" contained in a folder named "Wilbur_files", all of this will be shown:

C:\Temp2\Site\Wilbur_files\button_topic_new.gif
C:\Temp2\Site\Wilbur_files\button_topic_reply.gif
C:\Temp2\Site\Wilbur_files\file.png
C:\Temp2\Site\Wilbur_files\icon_biggrin.gif
C:\Temp2\Site\Wilbur_files\icon_confused.gif
C:\Temp2\Site\Wilbur_files\icon_contact_pm.gif
C:\Temp2\Site\Wilbur_files\icon_cool.gif
C:\Temp2\Site\Wilbur_files\icon_lol.gif
C:\Temp2\Site\Wilbur_files\icon_mini_faq.gif
C:\Temp2\Site\Wilbur_files\icon_mini_login.gif
C:\Temp2\Site\Wilbur_files\icon_mini_members.gif
C:\Temp2\Site\Wilbur_files\icon_mini_message.gif
C:\Temp2\Site\Wilbur_files\icon_mini_profile.gif
C:\Temp2\Site\Wilbur_files\icon_mini_search.gif
C:\Temp2\Site\Wilbur_files\icon_post_quote.gif
C:\Temp2\Site\Wilbur_files\icon_post_report.gif
C:\Temp2\Site\Wilbur_files\icon_post_target_unread.gif
C:\Temp2\Site\Wilbur_files\icon_question.gif
C:\Temp2\Site\Wilbur_files\icon_razz.gif
C:\Temp2\Site\Wilbur_files\icon_redface.gif
C:\Temp2\Site\Wilbur_files\icon_smile.gif
C:\Temp2\Site\Wilbur_files\icon_user_offline.gif
C:\Temp2\Site\Wilbur_files\icon_user_online.gif
C:\Temp2\Site\Wilbur_files\icon_user_profile.gif
C:\Temp2\Site\Wilbur_files\icon_wink.gif
C:\Temp2\Site\Wilbur_files\site_logo.gif
C:\Temp2\Site\Wilbur_files\spacer.gif
C:\Temp2\Site\Wilbur_files\stylesheet.css
C:\Temp2\Site\Wilbur_files\wilbur.jpg

If you know that your file was exactly "wilbur.jpg", then it'll just return

C:\Temp2\Site\Wilbur_files\wilbur.jpg

in the search. No boolean search allowed, or other option (limit entries to 15 max/both previewed lines of contents and lines of entries being user defined, as Hallgren said, for instance).

OF COURSE Don's approach is a far better way, but it seems it'll take quite a time to get the job done... =)

Re: Search results request

Posted: 01 Dec 2010 19:51
by diarrhio
So it's been a bit over a year since this topic was discussed. Any chance this feature can move higher up in the priority list?

Thanks,
D

Re: Search results request

Posted: 09 Dec 2010 08:52
by admin
diarrhio wrote:So it's been a bit over a year since this topic was discussed. Any chance this feature can move higher up in the priority list?
No, still the current roadmap has priority, sorry.