Flexible search in name and path without trailing \

feature
#1

Hi,
I want to suggest a little enhancement for the search including parts of the path.

The necessity to add a \ to the words that should be considered as parts of the path is cumbersome if you can’t remember exactly which words are part of the path and which are part of the filename itself.

Let me give an example …

The following file could show the timetable of one of my kids
=> peter_schedule_1C.jpg
BUT if I want to keep all the school related files from Peter in one folder this could just as well look like this
=> .\school\peter\schedule_1C.jpg

What I’m trying to say is…

… it depends on the situation and your personal preference how you organize your files whether ‘peter’ is part of the filename or part of the path.
But, when I want to quickly search for the schedule of Peter I don’t want to try different variations -> I just want to type [peter schedule]

Sorting …

The fact that words match either the file name or the path could be used for the ranking/sorting.
I would assume files where all words have a match in the file name should be ranked higher than those with matches in the path.

#``
If there are users out there that prefer the current behavior => this could be an option.

I hope you like the idea. :slight_smile:
Chris

是否能检索完整路径
#2

Hi Chris,

In fact the trailing \ makes the search syntax much more flexible instead of cumbersome.

For example, if you’re looking for .\school\peter\schedule_1C.jpg, you can first simply try to type schedule as usual. Then if Listary gives you too many unexpected results, you can continue typing schedule peter\ to narrow down the results.

\ allows you to change your existing search query to a parent folder search query anytime, and only when you need it. Please check this page for more info: http://www.listary.com/docs/advanced-search-syntax#Specify_parent_folder_names

#3

Hi Channing,
thanks for your reply.

In your example you are assuming that one already knows which keywords are part of the file name and which are part of the path - but that’s not always the case.

The problem isn’t that I can’t narrow down the results. That works fine with the current solution.
The problem occurs when you get no result (or not the result you are searching for)…

If I enter peter schedule I get no result (or at least not the result that I’m searching for).
The same for peter schedule\ and of course if I simply enter peter.

The problem is that I used a keyword that is associated with the file but unfortunately is part of the path.

It get’s even worse if you are searching for files of your family members or coworkers. Then there is little chance that you guess what words went into the path respectively the file name.

The question is: why shouldn’t Listary take the hassle out of this situation?

Google search is famous for it’s clever ranking - not for filtering out results in the first place. If the file I am looking for is not in the list, I have a completely different problem.

I hope my suggestion would solve both problems. The user could just enter words associated with the file and the ranking/sorting tries to put the most relevant matches on top of the list.

So I think I don’t suggest to alter the feature of narrowing down the search,
but to consider the full path name while searching for files.

Does this make sense?

#4

Thank you for your reply.

It’s possible to implement such a feature, but I’m a little concerned about performance. The number of valid combinations can grow very quickly with the number of keywords. For example, there are 7 different combinations for 3 keywords: a b c, a\ b c, a b\ c, a b c, a\ b\ c, a\ b c, a b\ c. This means that Listary will take much more time to finish the search. So I need to think very carefully about adding it.

It took me some time to really understand your need because I had never encountered the same issue. No matter the file name is peter_schedule_1C.jpg or school\peter\schedule_1C.jpg, I would always type schedule first because it’s the most describing word of what I’m looking for, and it’s very likely that Listary can find the document by this single word directly. If there are too many results, I’ll continue typing schedule peter. Now if the file name is peter_schedule_1C.jpg, I’ve got it. However if I get no result, all I need to do is appending a : schedule peter\

#5

Thanks for considering this request.

I agree that this is an important point to consider and I hope you appreciate the challange :wink:

If you get this working with acceptable speed I think it would well be worth the effort and opens a whole new world of use cases for Listary.