Feature Request - Search: show *all* paths that include search terms

[jaysmithgit]

I understand that the current search behavior -- which I don't see a way to use any differently or any other options -- is to enter a string and if you don't see what you are looking for, enter a slash "/" and that will allow showing more results including paths where the search string is not included in thelater part of the path .

However, the logic flaw in that -- for me -- is that the user does not necessarily already know how many other complete folder paths may exist (we have well over 10,000 folders in a deep and broad structure), thus the user does not automatically know to take an action to see something that they don't know exists... because they can't yet see it.

If there was a selectable option/setting "show all complete paths that include search string", I would use that 99% of the time.

It would be fine with me if this option/setting was only available in Pro.

Thanks.

[RealRaven2000]

In a way, it already does this (of course the folders need to be present in the folder tree). if you enter only 1 or 2 characters they have to be the start of the folder name. with 3 and more characters it will show all folders that match (no matter where they are, os regardless of on which server or under which subfolder they exist). The hardest part is to decide which ones should be at the top of the list. I do not show lists that are 100s of items long so there is a maximum number of results where it cuts off.

You can however change the number of results by right-clicking on the quickMove option in the premium features box:

you can then edit the numeral value in extensions.quickfolders.quickMove.maxResults

[jaysmithgit]

Axel,

Unfortunately, that is not my current experience (and I am using a profile where the .msf files ARE all present).

The test search string is "swipe". It appears in the paths of two different areas in my structure, but ...

Searching for "swipe" (which is 5 letters, so meets the test you mentioned) gives results of the two main paths that include "swipe" but NOT any results for the sub-folders below which actually contain mail messages.

For example, "swipe" results in:

.../..../..../swipesimple
WITH ALL the leading path in front showing, but NOT the terminal folder that contains mail.
(this is just a folder/directory, does not contain any mail messages)

"swipe" does NOT provide the desired result, with the terminal mailbox, which is:
.../..../..../swipesimple/support

If I instead search for "swipe/" (with trailing slash) the results ARE the desired folder:
swipesimple >> support
But now WITHOUT any of the leading path information showing at all!

The missing leading path is a different problem.
(There can be situations that if it does not show the leading path info, I might not know if the terminal folder (containing mail messages) is the desired folder; there are many cases where I have multiple instances of the same terminal folder name (for example, "support") in various places in the large structure.
??? Should I post this as a different issue?

So, unless I have misunderstood you, the behavior I am seeing is not quite what you described / expected.

It might be easier to communicate if I could email you a couple screen shots. However, because this is a live, sensitive structure I don't want to post images on the web. May I email them to you (I have your address)?

Jay

[RealRaven2000]

I think this can be improved, we have a parameter for the maximum path depth (how many folder names including parents / grandparents are shown) but apparently it only works if you enter the simple folder name, or you enter "n" predecessors and mirrors this in the results. In this example I see 3 (matching) parts because I entered 3 names:

I think this should / could be changed to always show (up to) the number of parts set in the maximum path depth:

[jaysmithgit]

I certainly agree and I would welcome that change to always "show (up to) the number of parts set in the maximum path depth:"

A couple thoughts...

a) I had already set my "Maximum path depth" to 12 (since I think that is about the depth we have here), but I obviously misunderstood the meaning of that setting. I had thought it was the depth to which the search was to be done. I wonder how many other users have the same misunderstanding? Now that you point it out today, I can clearly see that being next to "Display Format" that setting is about the display -- but I did not understand it then. You may think this is redundant and unnecessary, but I would suggest adding the word "display" somewhere in "Maximum path depth".

b) When you are designing and working with this feature, please never forget that the user, especially in an organization with a shared (/public) IMAP structure, very often may not know the details of the structure in which the desired folder is located. For example...

.../.../.../customers/a-g/a/adams_fred
.../.../.../customers/a-g/a/adams_george
.../.../.../customers/a-g/b/bundt_alvin
.../.../.../customers/a-g/ca-cl/clements_mary
.../.../.../customers/a-g/cm-cz/colberg_john
.../.../.../customers/h-m/ha-hi/hassan_ahmed

The user does not necessary know/remember these groupings (a-g vs g-m) or (a vs ca-cl vs cm-cz), etc.

(I use these kinds of structures so than any one "containing" folder does not have more than several hundred mail-containing folders inside it.)

[RealRaven2000]

a) I had already set my "Maximum path depth" to 12 (since I think that is about the depth we have here), but I obviously misunderstood the meaning of that setting. I had thought it was the depth to which the search was to be done. I wonder how many other users have the same misunderstanding? Now that you point it out today, I can clearly see that being next to "Display Format" that setting is about the display -- but I did not understand it then. You may think this is redundant and unnecessary, but I would suggest adding the word "display" somewhere in "Maximum path depth".

This can potentially be a long string when translated into other languages, I thought the context was clear from the line "Display Format" in which it is displayed:

Since space especially on this page is at a premium, I may put in a separating line above (showing a colored panel underneath is potentially difficult because both themes and the OS could re-skin the dialog face system color.

b) When you are designing and working with this feature, please never forget that the user, especially in an organization with a shared (/public) IMAP structure, very often may not know the details of the structure in which the desired folder is located. For example...

.../.../.../customers/a-g/a/adams_fred
.../.../.../customers/a-g/a/adams_george
.../.../.../customers/a-g/b/bundt_alvin
.../.../.../customers/a-g/ca-cl/clements_mary
.../.../.../customers/a-g/cm-cz/colberg_john
.../.../.../customers/h-m/ha-hi/hassan_ahmed

The user does not necessary know/remember these groupings (a-g vs g-m) or (a vs ca-cl vs cm-cz), etc.

I can see that subgrouping makes it harder for your users. I don't know how to fix it. Considering the example of trying to find the folder customers/a-g/ca-cl/clements_mary they would have to know that there are 2 (potentially irrelevant) folders they would need to skip, and would have to enter something like cust/*/*/cl to get a match. (We don't support wildcards at the moment, so the only way they could get there would be via cust/a/c/cle). What did Nostalgy do in this case?

Let's focus on one feature per issue, so in this isue #155 I will only treat the display format. I never to multiple items in the same issue because then they can never be really completed.

[jaysmithgit]

I apologize for getting into more than one item/subject in an issue. I completely understand.

I am not sure exactly which aspect you are calling "display format" (as in" so in this isue #155 I will only treat the display format.") so I don't know which item/part/subject to break out into a different issue posting.

I can see that subgrouping makes it harder for your users. I don't know how to fix it. Considering the example of trying to find the folder customers/a-g/ca-cl/clements_mary they would have to know that there are 2 (potentially irrelevant) folders they would need to skip, and would have to enter something like cust///cl to get a match. (We don't support wildcards at the moment, so the only way they could get there would be via cust/a/c/cle). What did Nostalgy do in this case?

In answer to your question, Nostalgy++ seems to treat every folder path as a literal string and it seems to treat the search query string as if is has a "*" (asterisk) wild card on either end.

and so in the example
../../../customers/a-g/ca-cl/clements_mary
you could find this item by any number of searches (some obviously much better than others!), such as:
mary (results: all occurrences of *mary* in the structure)
clem (results: all occurrences of *clem* in the structure)
ca-cl (all members of that folder -- too many!)
etc.

In Nostalgy++ I typically searched for "clem" or maybe "clements_m" -- if I had many people with the name clements

Since Nostalgy seems to treat the entire path as a literal string, a search for /clem

FINDS ca-cl/clements_mary
but AVOIDS FINDING ca-cl/calvert_clem'

You asked... I am not suggesting that Nostalgy++ has the best method, etc.

[RealRaven2000]

I apologize for getting into more than one item/subject in an issue. I completely understand.

I am not sure exactly which aspect you are calling "display format" (as in" so in this isue #155 I will only treat the display format.") so I don't know which item/part/subject to break out into a different issue posting.

I understand that this issue is about showing more information in the individual items of the dropdown (not more results numerically) when you are entering a "parent/childfolder" string combo. The way these menu items are shown at the moment in this case only reflects the number of parent folders you have entered in the search mask, but it should really show the "max path items" that can be configured, just like when you search for a plain folder name. This way of presentation of a match in the menu is what I call "display format". This is what this issue is about.

I can see that subgrouping makes it harder for your users. I don't know how to fix it ..... What did Nostalgy do in this case?

In answer to your question, Nostalgy++ seems to treat every folder path as a literal string and it seems to treat the search query string as if is has a "*" (asterisk) wild card on either end.

This applies to "in-text search" from 3 characters onwards in QuickFolders, too. With 2 characters it will look for only the start of a string (but cuts up folders names containing spaces or underscores). But you are not forced to enter the full name of the parents, only the starting letter(s).

In Nostalgy++ I typically searched for "clem" or maybe "clements_m" -- if I had many people with the name clements

Since Nostalgy seems to treat the entire path as a literal string, a search for /clem

FINDS ca-cl/clements_mary
but AVOIDS FINDING ca-cl/calvert_clem'

Ok, so you can use "/" in Nostalgy too. but have to enter full folder names for all parents (or at least the end part of the name of the first parent, which is not so useful, e.g. "-cl/cle".

[RealRaven2000]

I think I am misunderstanding this whole issue. Did you mean to write:

show all subfolders of a match recursively? (which could be potentially 1000s of folders).

[jaysmithgit]

Ok, so you can use "/" in Nostalgy too. but have to enter full folder names for all parents (or at least the end part of the name of the first parent, which is not so useful, e.g. "-cl/cle".

No. In Nostalgy++ the "/" is just an ordinary character that is part of the literal path string. It has nothing to do with parents or children.

Think of it this way... In Nostalgy++ ... It may not be how it actually works, but this is what it seems like in simplistic terms:

Make a single list of all the *complete+ paths of every folder in the mail system.

/
/a
/a/123
/a/123/b
/a/123/b/joe
/a/123/b/harry
/a/123/b/fred

In that example data set:
If you search for "a" the result will be a list of ALL of them.
If you search for "123" OR for "12" (or 1 or 2 or 3) the result will be 5 of them
If you search for "/b/" the result witll be 3 of f them.
If you search for "joe" OR "b/joe" the result will be one of them (/a/123/b/joe).
If you search for "h" the result will be one of them (/a/123/b/harry).

Obviously this example is too simple and, yes, if on my system I search for "a" I will get thousands of results. But, I DON'T search for "a" -- I search for something practical like "albert".

[jaysmithgit]

I think I am misunderstanding this whole issue. Did you mean to write:

show all subfolders of a match recursively? (which could be potentially 1000s of folders).

I should have used the word "list" instead of the word "show" -- about having the option to use a different method of searching.

My original issue was intended to be about quantity -- not so much about display.

YES, the result could show thousands of folders, but users are smart enough to search for what is practical. Some humans are much better at doing than machines, though perhaps soon the machines will be better at it.

This issue was intended to be about "LIST all of the paths that have a textual match in any part of the path and NOT about "display the whole length of the path or in a certain way". That being said, I am accustomed to displaying the ENTIRE path.

I am not sure what you mean by "recursively" in this particular context.

I mean to say...

1. For EACH "hit" of search result, LIST one line of result.
2. Search for the search-string anywhere in the entire path, from the root all the way to the terminal folder (i.e. last folder in path)
3. If a search string appears more than once in path, it would be best to present only one line of listing, not duplicate.
4. It does not matter where the search string matches to text in the path -- any match is a match.

EXAMPLE:

EXISTING PATHS ARE:

/jsa/test
/jsa/office
/jsa/house
/jsa/house/test
/jsa/pets/mice

SEARCH STRING = "test"

RESULT LIST:

/jsa/test
/jsa/house/test

SEARCH STRING = "ice"

RESULT LIST:

/jsa/office
/jsa/pets/mice

SEARCH STRING = "jsa"

RESULT LIST:

/jsa/test
/jsa/office
/jsa/house
/jsa/house/test
/jsa/pets/mice

SEARCH STRING = "a/h"

RESULT LIST:

/jsa/house
/jsa/house/test

Does this help?

[bobmorane06]

Hi Jay and Axel, let me add my request, which may be aligned to what Jay is asking for. If you would like me to open another issue I'll be happy to.

I used to use Nostalgy, then moved to Outlook and used Techit SimplyFile and I ended up finding SimplyFile more powerful. What I miss in quick folders is the ability to look for 2 terms in a a folder tree, from parent folder and folder name and in any sequence.

eg for the examples below:

(1) Customer1 May 2021 invoices
(2) Customer1 June 2021 invoices
(3) Customer 1 contracts
(4) Contracts Customer9
(5) Invoices June 2020 Customer 9

"Customer1 inv" returns (1) (2)
"cust inv" returns (1) (2) (5)
"Customer9 contr" returns (4)

I'm thinking that one way of doing this is:

• Create a list of all matching strings until the user types a space in the search field
• After the space make a new search in that intermediate list (on the complete strings)

=> this is more powerful than Nostalgy++ regex that only works if one remembers in which order the strings are:
In Nostalgy++ "cust.*inv" would return (1) (2) BUT NOT (5)

[bobmorane06]

BTW, this is similar to the behavior of Void's Everything https://www.voidtools.com/ that does a blazing fast search through all file names in my system (a tool I couldn't leave without :-))

[RealRaven2000]

BTW, this is similar to the behavior of Void's Everything https://www.voidtools.com/ that does a blazing fast search through all file names in my system (a tool I couldn't leave without :-))

Interesting - I see that this one supports both wildcards (*.exe) and special syntax (parent:). Not too sure whether wildcards may be too complicated for most users and thus not worth the effort to implement, but I have the "parent" syntax implicitely by adding the (start of) parent name followed by a slash.

As to your example case "cust inv" it uses the start of the (split) names within a long folder name implictely but in arbitrary order. So you need to know the start of the words in the string, which is a reasonable intuitive restriction. Bear in mind that long folder names like this may be a bit of an edge case - a lot of people may have used the folder tree for doing such complexity - but can still be confused of the order in the hierarchy. consider the following [parent/child] folder combinations:

(1) Customer1/invoices/june
(2) Customer1/june/invoices
(3) June/Customer1/invoices
(4) June/Customer1 - invoices

Let's assume the user has some or all of these in their folder hierarchy, so he wouldn't necessarily know whether to look for
cu/in/j
ju/cu/in
ju/in

(this is spreading out the complexity of your requirement across folders) each of these searches currently will only return a subset of the searched folders. The question is, should entering multiple strings (delimited by space) also match these across the full path in arbitrary order. This would be an expansion of the original requirement "all paths that include search string", but (probably) also cover your use case. It would possibly also return a much larger result set, but somewhat alleviated through the restriction of have to enter "from start of the string". Thoughts?