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?

[RealRaven2000]

Just an additional thought on parent / child hiearchies (based on the current algorithm which takes them in order)

(3) June/Customer1/invoices

this is currently found when entering "ju/cu/in" but not when entering "ju/in" as the algorithm doesn't "skip" any folders. Notwithstanding if I remove the "given order", I wonder if skipping in between folder names would be a good idea... so that "ju/in" would also implictely mean to cover all "ju/../in" combos. The browser console in Tb / Firefox has a similar matching mechanism, by skipping all characters in between matches, which casts a wide net that becomes rapidly smaller the more letters (in sequence) are entered. As example, if you go to the debugger in the toolbox and hit Ctrl+P to open files, you get this search box - which neatly highlights the matching letters within all matches via bold font:

this one is pretty helpful if I roughly know the file name I am looking for (e.g. quickfolders-folders-categories.js) but don't know the exact spelling (or whether i users - or _ or other characters for delimiting)

[bobmorane06]

Thanks Axel. From your comments, I assume that your algorithm follows a tree structure, where when you find a match with the first expression, then you look in all subfolders for the next expression (when using / to separate them).

Whereas it's my impression that SimplyFile and Everything generate an index of all folder paths / filenames and then make a search in that index => I assume that it makes it easier to look for 2 expressions in any order (look for the 1st expression to generate a new index of paths including that expression, then look for the 2nd expression in that new index).

In my particular case my email folder naming isn't super-consistent. Sometimes I'll have Customer1/Invoices/Year, but other times I may have Customer2/2021 Invoices and Customer2/2020 Invoices. So the use of / isn't always working in my scenario.

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

Actually the search works on any character even if not the start of a name, i.e. "ust inv" would work too

The question is, should entering multiple strings (delimited by space) also match these across the full path in arbitrary order

I would return everything, but displaying the ones matching the sequence at the top of the results :-)

[RealRaven2000]

Thanks Axel. From your comments, I assume that your algorithm follows a tree structure, where when you find a match with the first expression, then you look in all subfolders for the next expression (when using / to separate them).

no not really. In a nutshell, the algorithm iterates ALL folders (in my case that's 1450 folders) matches the folder name and then matches the parents (if the search string contains "/"). But obviously nothing is hammered in stone, I can always extend the algorithm. But definitely at the moment it only is interested in the parts before "/" as parent names. But it doesn't "drill down", it actually "follows upwards" from the child name. So in your case I could just add the multipart matching if you use space to delineate the folder name parts and do the matching within the folder name (I already break it apart anyway in order to mot stuff like preceding _Name and composite names "name1 name2" so that I can match the (now singular) text within these broken parts. It would just mean adding multiple match tests and making sure all are contained in the folder name.

Whereas it's my impression that SimplyFile and Everything generate an index of all folder paths / filenames and then make a search in that index => I assume that it makes it easier to look for 2 expressions in any order (look for the 1st expression to generate a new index of paths including that expression, then look for the 2nd expression in that new index).

I think "Everything" probably flattens the filenames in a list and then uses regular expressions to match; that's just an implementation detail though

In my particular case my email folder naming isn't super-consistent. Sometimes I'll have Customer1/Invoices/Year, but other times I may have Customer2/2021 Invoices and Customer2/2020 Invoices. So the use of / isn't always working in my scenario.

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

Actually the search works on any character even if not the start of a name, i.e. "ust inv" would work too

Currently, I am not doing in text match unless you enter 3 characters or more (2 characters assumes it's the start of a word), but it may return a lot of unwanted results if the order is arbitrary too, which can make the whole result list useless. I have to be careful not to make it harder for all users in order to satisfy the needs of a few.

The question is, should entering multiple strings (delimited by space) also match these across the full path in arbitrary order

I would return everything, but displaying the ones matching the sequence at the top of the results :-)

One problem is that at the moment I do have "/" as a special character to show that I am interested in subfolders - and I also offer to create a new folder based on this, so you can file away your mails not knowing whether the folder exists:

This is actually very powerful as you can move mails to desired targets in a single operation (and complete your folder structure if you need to create Customers/Fred while you are filing mails away). Going across different folders in random order somewhat complicates this. So maybe in the first iteration let's just omit the parent/child relationship and just say if you enter 2 words with a space it tries to find folders that have both those texts in the name.

As regards "entire path" matching I think we should also circle back with @jaysmithgit because I am not quite sure what he wanted exactly. At the moment everything before a slash is treated as "start of a parent folder name", but it has to be the direct parent of the match. E.g.

Co/te/foo

will match COrrespond/TEst/snafoo

but not cosCO/enTEr/snafoo

(as said before the last child name "foo" supports in text matching with length >= 3 characters)

[RealRaven2000]

Here is a first test version. So the parent algorithm is still the same (if you enter parent names, they need to be in the correct order without omissions, and you need to enter the start of the name). The folder name portion (after the last slash, if you enter a parent) will do a multi-string search if you enter a space - however I only match the individual substrings from the start. In the algorithm I iterate through the search words, split the folder name into an array (I have added a regulat expression that splits off the most common delimiter characters: - _ + & . and overwrite the first match of the search string with "####", then repeat with the next search word. You can still add a parent name if you wish to further restrict results. The order of words is not important as I iterate the whole array for each pass. The search words need to be at the beginning of each "folder word" for the moment. See if you can test this one for a while.

Quick test:

With added parent folder:

So here it the test version: QuickFolders-wx-5.6pre6.zip

To install, download the zip file and then drag the zip file into Add-ons Manager. (github doesn't allow .xpi files in comments)

[RealRaven2000]

PS: I made mistake with my version numbering - this should actually have been 5.6pre199. Just in case you downloaded a prerelease with a higher version such as 5.6pre150 etc. Next versions will reflect the correct number again.

[RealRaven2000]

...and here is a version for Thunderbird 68. I still have my production profile on that version so I decided to back-port. Nice example for a search:

QuickFolders-wx-4.22pre10.zip To install, download the zip file and then drag the zip file into Thunderbird 60 - 68 Add-ons Manager.

[jaysmithgit]

As regards "entire path" matching I think we should also circle back with @jaysmithgit because I am not quite sure what he wanted exactly.

What @jaysmithgit (me) was hoping for was to, when/after typing the search string, have a way to see the full paths of all of the paths that include the search string (within reason; I understand that there needs to be a certain number of letters typed, etc.).

The problem I am having is that I don't know how many forward slashes (/) I have to type following the search string because in thousands of folders I don't remember at which level (how many folders deep) the target folder is.

Thus I have to type the initial search string, look at the results list, then possibly type a slash, then look at the results list again, then possibly type another slash, then look at the results list again, then possibly type another slash, then look at the results list again, then possibly type another slash, then look at the results list again, then possibly type another slash ...

As an example:

Search string: grude

Possible paths:

correspondence - grude_axel >> thunderbird >> quickfolders       (4 levels) 
software - thunderbird >> addons >> quickfolders >> grude_axel   (5 levels)
pending_projects - grude-axel                                    (2 levels)
personal - friends >> grude_family                               (3 levels)

Another example is a folder structure for an organization with which I may have many types of and reasons for contacts, thus many different "departments", etc. in this kind of example, the terminal folder names (where I will actually file the mail messages) are generally the same for many different organizations, thus I have to start with typing the name of the organization and then select what "department" I want, etc.

I would like to be able to see ALL of the following when I type "cnn_tv"

vendors - cnn_tv >> _general
vendors - cnn_tv >> broadcast >> editorial >> _general
vendors - cnn_tv >> broadcast >> editorial >> letters_to_editor
vendors - cnn_tv >> broadcast >> editorial >> reporters >> grude_axel
vendors - cnn_tv >> broadcast >> editorial >> reporters >> cooper_anderson
vendors - cnn_tv >> website >> editorial >> reporters >> acosta_jim
vendors - cnn_tv >> website >> advertising >> _general
vendors - cnn_tv >> website >> advertising >> 2021_plans
vendors - cnn_tv >> website >> advertising >> 2022_plans
vendors - cnn_tv >> website >> advertising >> products >> wonder_widget
vendors - cnn_tv >> website >> advertising >> products >> super_widget
vendors - cnn_tv >> website >> contacts
vendors - cnn_tv >> accounts_receivable >> _general
vendors - cnn_tv >> accounts_payable >> _general
vendors - cnn_tv >> management >> _general

Notice that many folders may have the name of "_general". It is useless to type "_general" because I probably have 300 mailboxes (of many thousands) that are "_general". (On our system, the underscore character sorts to the top of a listing.)

I am hoping for a "switch" that a Pro user can turn on/off that allows searching EITHER a) using the current method OR b) searching and displaying the entire path (in this example, "cnn_tv")

I hope that this helps.

Jay Smith

[RealRaven2000]

Let's grab this example:

I would like to be able to see ALL of the following when I type "cnn_tv"

so at the moment you can type "cnn_tv/" (note the trailing forward slash) which only shows direct child folders - but you could have potentially 100s of subfolders under cnn_tv, are you sure you would want to list them all at this stage? The detail is important. I think it only makes sense to drill down recursively if more criteria (e.g. a second word) were entered.

If everything was shown, this would obviously have to be sorted by complexity, so it would be sorted like this:

vendors - cnn_tv >> _general
vendors - cnn_tv >> accounts_receivable >> _general
vendors - cnn_tv >> accounts_payable >> _general
vendors - cnn_tv >> broadcast >> editorial >> _general
vendors - cnn_tv >> broadcast >> editorial >> letters_to_editor
vendors - cnn_tv >> broadcast >> editorial >> reporters >> grude_axel
vendors - cnn_tv >> broadcast >> editorial >> reporters >> cooper_anderson
vendors - cnn_tv >> management >> _general
vendors - cnn_tv >> website >> advertising >> _general
vendors - cnn_tv >> website >> advertising >> 2021_plans
vendors - cnn_tv >> website >> advertising >> 2022_plans
vendors - cnn_tv >> website >> advertising >> products >> wonder_widget
vendors - cnn_tv >> website >> advertising >> products >> super_widget
vendors - cnn_tv >> website >> contacts
vendors - cnn_tv >> website >> editorial >> reporters >> acosta_jim

Notice that many folders may have the name of "_general". It is useless to type "_general" because I probably have 300 mailboxes (of many thousands) that are "_general". (On our system, the underscore character sorts to the top of a listing.)

I am hoping for a "switch" that a Pro user can turn on/off that allows searching EITHER a) using the current method OR b) searching and displaying the entire path (in this example, "cnn_tv")

neither of these are helpful (the current method doesn't work as it only looks for the terminal folder) and showing everything from a single word gives a useless (too large) result set. We need to come up with something that is useful to everybody and has an intuitive, easy to type / remember syntax.

So the question is whether using an existing search expression "cnn/gen" (you can omit the _ in a folder search) should display this result set:

vendors - cnn_tv >> _general
vendors - cnn_tv >> accounts_receivable >> _general
vendors - cnn_tv >> accounts_payable >> _general
vendors - cnn_tv >> broadcast >> editorial >> _general
vendors - cnn_tv >> management >> _general
vendors - cnn_tv >> website >> advertising >> _general

and whether this would be helpful (you would still need to know that general is a subfolder and that the cnn_tv folder is above in the hierarchy) - this could be achieved by adding an option (search all parents) or by some special syntax such as using e.g.

cnn>gen

Basically having a new operator such as > for recursive / skipping folders instead of / for direct folders. Hard enough to document but it may be worth making a test version. Also on some non-English keyboards the > key is hard to reach so maybe . or , would be a better choice.

[RealRaven2000]

Just to clarify, having the "gen" on the right hand side of "parentpath>" would be quite important, you need to know (at least part of) the final folder name. Or the final parent, followed by "\" to list all children. A workaround for no knowing the final folder name would be syntax like this cnn> lists all direct children cnn>> [potentially] could list all grandchildren (skipping children) - but would lead to a much bigger result set 'cnn>>>' lists all grand-grandchildren - skipping grandchildren - again larger resultset but we have eliminated the previous level.

If possible, I want to avoid having to scroll (or look) through too many results on my screen. It certainly wouldn't help to have to scroll down a menu list in order to find out that what we need wasn't there in the first place and have to enter more. It's better to have a restriction and force the user to enter one or two more letters to get much closer to the intended search result.

[jaysmithgit]

Axel, In reply to both your posts in the last couple hours...

a) You are correct that I did not have the results listed in proper sorting order. I was careless. You are correct, except you also had one in the wrong order (on of the terminal folders). :-)

b) I agree with you "It's better to have a restriction and force the user to enter one or two more letters to get much closer to the intended search result." However, the most important thing to remember about that is that the user may not know what additional characters they must enter. However, otherwise, in principle, I am okay with that.

c) I somewhat disagree with you about the length of the results list. While I do understand that a very long list can be a problem, particularly for users who may be using a large font or magnification size due to vision problems, the information in that list would inform the user what additional characters to type for "b" above. To my knowledge, Nostalgy++ uses a USER-DEFINED limit on the quantity of search results; when I was using Nostalgy, I had that quantity set to 30 and that worked very well for me (20 was not enough) and for my screen resolution & font size. I think the users will quickly adjust to a quantity that is useful for them and quickly adjust to viewing the results list to get the additional information of what further characters they may need/want to type. It is my opinion that you may be too much concerned about the length of search results lists. Users will quickly adjust. Please keep in mind that this is an "advanced feature" that is really intended for users with thousands of folders -- those users are, almost by definition, accustomed to a bit of complexity.

d) From your suggestion... (though the separator/character might have to be different as you mentioned)

This WOULD be useful to me (even if a long results list)

cnn> lists all direct children

I do NOT think these would be useful for me:

cnn>> [potentially] could list all grandchildren (skipping children) - but would lead to a much bigger result set 'cnn>>>' lists all grand-grandchildren - skipping grandchildren - again larger resultset but we have eliminated the previous level.

These two are just another version of the same problem that caused my original suggestion. Anytime one is skipping levels, then one is forced to already know what is between levels or one can't know how many ">" to type. This is really not much different than typing various quantities of "/".

e) Regardless of what the outcome of all this is, it is important that the full path actually be displayed to the user. Not an abbreviation of the path and not just the final bits of the path. This is part of my original difficulties.

f) You mentioned that the ">" character is difficult on some keyboard layouts. I agree that it is important to avoid such difficulties. At the same time, whatever character is used, it should be one that is NOT "legal" in the actual folder names. I assume that "/" is NOT "legal" in a folder name, thus it should be a good separator. However "." [period] IS legal in a folder name even if not a good idea, thus NOT a good separator. I do not know if "," [comma] is legal, but even if it is legal it is a terrible idea in a folder name, thus I would be fine with using "," [comma] as a separator if that is easier for more users.

g) I am just checking... can "/' [forward slash] be double-purposed? In the current usage it is only at the end of the string for further searching on the path. It would be very convenient to use slash in the form of "cnn/gen" per the example you provided. Is that posssible without breaking the current functionality?

h) Can the separator easily be used more than once? Using your example, would "cnn/web/prod" be possible to only result in:

vendors - cnn_tv >> website >> advertising >> products >> wonder_widget
vendors - cnn_tv >> website >> advertising >> products >> super_widget

An important aspect of all this about which I am very mindful is that the development has to be easy for you to create and, even more important, it has to be easy for you to maintain over time, avoid conflicts with other features, etc.

Jay

[crablouis]

Long time (paying) user here. Just wanted to chime in to say that THIS IS THE ENHANCEMENT I'VE BEEN HOPING FOR. TBird, while nicely featured, really doesn't provide a way to search for folders. This QuickFolders enhancement does. This makes managing and using my current ton of folders as well as my decades of business and personal mail archives much easier and more practical. Thanks.

I do have one request. Whichever characters or operators are finally chosen as delimiters, "/" or ">" or whichever, please provide some kind of persistently visible reminder in the UI. Thanks!

[RealRaven2000]

We already have multiple "/" syntax for a long time, it was just not possible to "skip" folders. And it had the option of generating a new folder based on the matched path, if the last folder name entered cannot be matched.

So I made a test version for Thunderbird 68 that uses the alternative ">". The "create new subfolder" function there went horribly wrong, so I just removed the feature for this search. I am assuming if you want to search casting a wider net you may have a better idea that a folder already exists. Here is a test:

QuickFolders-wx-4.22pre25.zip

Needs to be tested out for a while, I have a feeling it's a little sluggish with over 1400 Folders but ymmv...

PS: to install download the zip file and drag it into Thunderbird 68 Add-ons Manager.

[jaysmithgit]

Axel,

Your message says Thunderbird 68 for the new test zip file.

Did you mean 78? I am on 78.7.1.

Please advise.

[RealRaven2000]

Your message says Thunderbird 68 for the new test zip file.

Did you mean 78? I am on 78.7.1.

No I indeed meant Thunderbird 68. I have to test it on my production profile (with almost 1500 folders), which is still in the older version of Thunderbird before I dare to transfer it into the code for Thunderbird 78. I have been writing and debugging this for about 6 hours today, and I doubt it's fully correct yet. I don't want to break the code in Thunderbird 78 until I am 100% sure that it won't break or bite me in the ass, and the most honest way to do this is to test it on my own heavy weight mail profile.

My main reason for not using Thunderbird 78 in production is that I have to convert Zombiekeys (an unpaid Add-on of mine) first which can take a few weeks. I didn't have enough downtime from supporting my other Add-ons (including QuickFolders) to do that.

[jaysmithgit]

I understand your problem and concern, but I don't have a functioning modern machine that is not already running 78. I do have a very old machine that can run 16, but that's no help.

I am not sure what to do other than wait until you are able to have a 78 testing environment.

Do you have any suggestions other than me buying and setting up another machine for either 68 or to dual boot different environments? I don't have a spare machine to experiment with dual booting, so I would have to buy another machine (I have already spent far too much on computers in the last 12 months, setting up remote workers, etc.).

[RealRaven2000]

I understand your problem and concern, but I don't have a functioning modern machine that is not already running 78. I do have a very old machine that can run 16, but that's no help.

I am not sure what to do other than wait until you are able to have a 78 testing environment.

Do you have any suggestions other than me buying and setting up another machine for either 68 or to dual boot different environments? I don't have a spare machine to experiment with dual booting, so I would have to buy another machine (I have already spent far too much on computers in the last 12 months, setting up remote workers, etc.).

If you wanted to test this you could use the Profile Manager to generate a fresh Thunderbird profile for testing - it would mean starting up with the command line parameter -ProfileManager. You can then create a new profile from there and use that with Tb68.

You would also have to disable auto-updates in settings / advanced / update:

If you connect to any production mail boxes make sure to set them not to remove any mail from the servers:

Note: If you upgrade an account from 68 to 78 it's hard to revert to the original.

Apart from that I will be building a version for 78 at some stage, but I have to tidy up the code first, I think there are still some issues.

[RealRaven2000]

Another test version, with some improved code.

QuickFolders-wx-4.22pre31.zip

This one has improved display of the matched path, maximum search results in Thunderbird 68 can now also be edited via right-clicking the quickMove checkbox in the "Premium Features" panel. This currently affects the number of direct search results not the number of items "create new subfolder", which will now really only be displayed when using only the / delimiter. Once a single > delimiter is used, the expanded search algorithm will be used instead, which is expected to return a larger result set.

[RealRaven2000]

Test version for Thunderbird 78: QuickFolders-wx-5.6pre205.zip

Use / for matching nested folders (direct children of the [start of] folder name entered before this operator). You can combine this multiple times:

note: the "create new subfolder" item is added if no perfect match for the target folder (search pattern on the right after last /) can be found and if the direct parent already has at least one child folder.

Use > at least once for matching all contained folders (all descendants, in entered order) that match the preceding pattern. This is a global switch so all other / operators will then also be used to "skip" descendants. ["m>qu/t" returns the same as "m>qu>t"]:

Word boundaries that can be processed for parent folders are . _ and space. (so entering "sto" will match parents "Flint.Stone" "Flint_Stone" and "Flint stone")

Use ' ' (Space character) for the target folder to match multiple words, in any order:

[jaysmithgit]

Axel, Thank you for the test version for TB 78. I hope to be able to set up testing of it this weekend and will report back. I am sorry I am not able to do it sooner.

[fredstluka]

Axel, Jay, and Bob,

It looks like this feature is coming along nicely.  Good job!

I like the choice of /, > and space as the delimiters with their various meanings.  Seems very powerful and relatively intuitive.

The only downside is that you're settling on the opposite convention from that used by CSS selectors, which may confuse some people (especially Web programmers).  In CSS, space means any descendant, and > means direct child only.  So:

CSS > == QF / CSS space == QF >

I'd leave it as you have it though, since I can't think of a better choice.  We clearly want / to keep its current and rather obvious meaning.  And I think we want space to keep its proposed meaning, since that's how most multi-word searches work (Google, Mac Spotlight, Thunderbird search, etc.).  So the only choice would be to use something other than > for the new meaning.  But > is such an obvious choice that I think it would be hard to justify NOT using it.

So, I propose you continue exactly as planned.  But expect some complaints someday from a CSS Web programmer...

--Fred

Fred Stluka -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates.

[RealRaven2000]

The only downside is that you're settling on the opposite convention from that used by CSS selectors, which may confuse some people (especially Web programmers).  In CSS, space means any descendant, and > means direct child only.  So: CSS > == QF / CSS space == QF > I'd leave it as you have it though, since I can't think of a better choice. 

I actually knew and thought about that, but it's relatively obscure for most users. another choice would have been \ but it is hard to enter on a German keyboard (you need the Alt-GR key), where-as > is on the lower row of keys in most locales. I would think that most users would probably settle on one of either and only use that depending on their setup and needs. I think it is more important to have a help panel close to the UI that explains the different choices in a few sentences.

This could either be a "help" item in the right-click menu (but then you would have to know that you can right-click on this icon, so it is kind off too obscure):

Or maybe I could have an additional ? icon displayed to the right of the search box, only when it is collapsed:

I can't really put the ? inside the search box for technical reasons, do you think it would be clear enough if displayed to the right? I could then add a callout / popup bubble with some short explanations.

[fredstluka]

Axel,

another choice would have been ||

Not a good choice because Microsoft Windows has blurred the distinction between / and .  They used \ despite all other OSs in the world using /, so, now all browsers are stuck supporting both as interchangeable.

I think it is more important to have a help panel close to the UI that explains the different choices in a few sentences.

A help panel would be a good idea, but yeah, it's hard to decide where to put it.

Or maybe I could have an additional |?| icon displayed to the right of the search box, only when it is collapsed

That may be the best idea.

--Fred

Fred Stluka -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates.

[RealRaven2000]

I think it is more important to have a help panel close to the UI that explains the different choices in a few sentences.

A help panel would be a good idea, but yeah, it's hard to decide where to put it.

Or maybe I could have an additional |?| icon displayed to the right of the search box, only when it is collapsed

That may be the best idea.

I actually meant to say "only when it is not collapsed" - I would show the icon only when the search box is shown. once clicked it could look something like this:

[fredstluka]

Axel,

Sounds good!  I'd change the last line from:

• Use > for skipping folders in between to:
• Use > for entering ancestor>searched folder

BTW, you said earlier:

I can't really put the |?| inside the search box for technical reasons

Are you aware of the "placeholder" attribute added to the HTML tag a few years back?  See:

• https://www.w3schools.com/tags/att_input_placeholder.asp

It might solve your technical problem of putting info inside the search box.

--Fred

Fred Stluka -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates.

[jaysmithgit]

Fred and Axel,

It's probably just me, but...

I have enough trouble understanding: "Use / for entering grandparent/parent/searched folder" but I really won't understand/remember "Use > for entering ancestor>searched folder"

FRED: Isn't my parent or grandparent my ancestor? Maybe "ancestor" is not what you meant? Or maybe you meant to use "/" instead of ">"? Now I am not sure which of the two commands you meant to comment about.

I understood Axel's "Use > for skipping folders in between" to be for something entirely different:

Using "acme > adams" to find the adams IN acme, and NOT the adams IN bigco. Providing the ability to skip over the intermediate folder levels -- very useful in my opinion

top > acme > clients > a-d > a > adams_joe
top > bigco > clients > a-d > a > adams_frederick

AXEL: Also, the there is a potential problem of miscommunication when using the word "entering". That can mean entering (typing) text. And it can mean "going into", as in "going into the folder and looking inside it" or "entering a house through the front door".

For me, the words won't matter either way because I will have to test it to see what actually happens and then remember what that means for my patterns of use. From that point on it becomes "muscle memory".

However, for a new user, I am concerned they might not quickly comprehend.

[RealRaven2000]

Aside from the onscreen help which I haven't started yet, I had done some improvements to the search algorithm - accepting the top result of the search menu when hitting the Enter key did not work if a search expression with a space (basically 2 or more words) was entered. This version accepts it:

QuickFolders-wx-5.6pre212.zip

To install, as always download the zip file and then drag it into Thunderbird Add-ons Manager.

[fredstluka]

Jay,

FRED: Isn't my parent or grandparent my ancestor? Maybe "ancestor" is not what you meant? Or maybe you meant to use "/" instead of ">"? Now I am not sure which of the two commands you meant to comment about.

Yes, parent and grandparent are ancestors.  Ancestor means anyone you're descended from, no matter how many generations away.  So that includes parent, grandparent, great grandparent, etc.

I like Axel's:

• "Use / for entering grandparent/parent/searched folder"

because it's a nice concise way of showing by example that with / you have to specify each generation.  Can't skip any. For example, this would NOT work:

• grandparent/searched folder

He kept it nice and short for the popup bubble.  I'm sure he'll also provide a way for the user to read more detail about exactly what works and doesn't work with /.

With ancestor, any of the following would work:

• parent>searched folder
• grandparent>searched folder
• great grandparent>searched folder
• etc.

You wouldn't have to explicitly specify each generation, like you would with /:

• parent/searched folder
• grandparent/parent/searched folder
• great grandparent/grandparent/parent/searched folder

So, we're looking for a nice concise one-line explanation of that for the popup bubble.  Again, I'm sure Axel will also provide a way for the user to read more detail about exactly what works and doesn't work with >.

Axel's wording:

• "Use > for skipping folders in between"

DOES convey this idea, for those of us who already know what he's trying to say.  But I'm not sure it's as self-explanatory as my proposed:

• "Use > for entering ancestor>searched folder"

I like mine better because it's an exact copy of the line for /, but with the relevant change:

• "Use / for entering grandparent/parent/searched folder"
• "Use > for entering ancestor>searched folder"

So, analytical users like me will tend to immediately compare the two, note the differences, and understand.

Also, I go into it with a programmer's mindset, knowing lots of places where I can use paths, wildcards, patterns, regular expressions, etc.  So, I'm immediately looking for the syntax that allows exactly one vs "many" (one or more).  For example:

• In a DOS, Windows, Mac, Unix, or Linux wildcard, it's ? for a    single char vs * for many chars.
• In a regular expression, it's . for a single char vs .* for many    chars.
• In CSS, it's > for a single level of nesting vs " " (space) for    many levels.
• In XPath, it's / for a single level of nesting vs // for many levels.

But, obviously not everyone thinks the way I do.  For example, you found my suggestion LESS obvious than Axel's.  So, he'll have to decide which is better for his target audience.  Either way is fine with me.

I understood Axel's |"Use > for skipping folders in between"| to be for something entirely different:

Using "acme > adams" to find the adams IN acme, and NOT the adams IN bigco.

Yes, that's what > means.  But depending on what you mean by IN, it's also what / means.

If IN means "directly inside of a folder, outside of any of its subfolders", that's /.  In English, I'd say the inner folder is a "child" of the outer "parent" folder.

If IN means "somewhere inside of a folder, including any of its subfolders at any level of nesting", that's >.  In English, I'd say the inner folder is a "descendant" (which may or may not be a direct "child") of the outer "ancestor" folder (which may or may not be a direct "parent" of the inner folder).

I don't see them as entirely different concepts.  I see them as variations on the same concept.  But again, that's me coming at it from a programmer's point of view.

Make sense?

AXEL: Also, the there is a potential problem of miscommunication when using the word "entering". That can mean entering (typing) text. And it can mean "going into", as in "going into the folder and looking inside it" or "entering a house through the front door".

Good point!  Maybe use the word "type" instead of "enter"? I tend to use use "enter" in such situations because the word "type" is more specific.  It implies that you have to manually type in the text.  Can't cut/paste it from somewhere else. In my mind, "enter" is less specific.  It means you can type it OR cut/paste it.  But again, I realize that I'm applying very specific programmer meanings to the words.  Whatever Axel chooses, to suit his target audience, is fine with me.

--Fred

Fred Stluka -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates.

[RealRaven2000]

ancestors is more concise but might not be understood by everyone. also i have to trust Google translate to come up with a localised metaphor without nein alle to check. that was the main reason why I used the term "skip".

but I was thinking of maybe providing some examples, space allowing.

On Fri 18 Jun 2021, 19:59 Fred Stluka, @.***> wrote:

Jay,

FRED: Isn't my parent or grandparent my ancestor? Maybe "ancestor" is not what you meant? Or maybe you meant to use "/" instead of ">"? Now I am not sure which of the two commands you meant to comment about.

Yes, parent and grandparent are ancestors. Ancestor means anyone you're descended from, no matter how many generations away. So that includes parent, grandparent, great grandparent, etc.

I like Axel's:

• "Use / for entering grandparent/parent/searched folder"

because it's a nice concise way of showing by example that with / you have to specify each generation. Can't skip any. For example, this would NOT work:

• grandparent/searched folder

He kept it nice and short for the popup bubble. I'm sure he'll also provide a way for the user to read more detail about exactly what works and doesn't work with /.

With ancestor, any of the following would work:

• parent>searched folder
• grandparent>searched folder
• great grandparent>searched folder
• etc.

You wouldn't have to explicitly specify each generation, like you would with /:

• parent/searched folder
• grandparent/parent/searched folder
• great grandparent/grandparent/parent/searched folder

So, we're looking for a nice concise one-line explanation of that for the popup bubble. Again, I'm sure Axel will also provide a way for the user to read more detail about exactly what works and doesn't work with >.

Axel's wording:

• "Use > for skipping folders in between"

DOES convey this idea, for those of us who already know what he's trying to say. But I'm not sure it's as self-explanatory as my proposed:

• "Use > for entering ancestor>searched folder"

I like mine better because it's an exact copy of the line for /, but with the relevant change:

• "Use / for entering grandparent/parent/searched folder"
• "Use > for entering ancestor>searched folder"

So, analytical users like me will tend to immediately compare the two, note the differences, and understand.

Also, I go into it with a programmer's mindset, knowing lots of places where I can use paths, wildcards, patterns, regular expressions, etc. So, I'm immediately looking for the syntax that allows exactly one vs "many" (one or more). For example:

• In a DOS, Windows, Mac, Unix, or Linux wildcard, it's ? for a single char vs * for many chars.
• In a regular expression, it's . for a single char vs .* for many chars.
• In CSS, it's > for a single level of nesting vs " " (space) for many levels.
• In XPath, it's / for a single level of nesting vs // for many levels.

But, obviously not everyone thinks the way I do. For example, you found my suggestion LESS obvious than Axel's. So, he'll have to decide which is better for his target audience. Either way is fine with me.

I understood Axel's |"Use > for skipping folders in between"| to be for something entirely different:

Using "acme > adams" to find the adams IN acme, and NOT the adams IN bigco.

Yes, that's what > means. But depending on what you mean by IN, it's also what / means.

If IN means "directly inside of a folder, outside of any of its subfolders", that's /. In English, I'd say the inner folder is a "child" of the outer "parent" folder.

If IN means "somewhere inside of a folder, including any of its subfolders at any level of nesting", that's >. In English, I'd say the inner folder is a "descendant" (which may or may not be a direct "child") of the outer "ancestor" folder (which may or may not be a direct "parent" of the inner folder).

I don't see them as entirely different concepts. I see them as variations on the same concept. But again, that's me coming at it from a programmer's point of view.

Make sense?

AXEL: Also, the there is a potential problem of miscommunication when using the word "entering". That can mean entering (typing) text. And it can mean "going into", as in "going into the folder and looking inside it" or "entering a house through the front door".

Good point! Maybe use the word "type" instead of "enter"? I tend to use use "enter" in such situations because the word "type" is more specific. It implies that you have to manually type in the text. Can't cut/paste it from somewhere else. In my mind, "enter" is less specific. It means you can type it OR cut/paste it. But again, I realize that I'm applying very specific programmer meanings to the words. Whatever Axel chooses, to suit his target audience, is fine with me.

--Fred

Fred Stluka -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/RealRaven2000/QuickFolders/issues/155#issuecomment-864221571, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQFVMS544PT47JA3RLPRH3TTOJRRANCNFSM44DSEUOQ .

[fredstluka]

Axel,

As I was writing out the previous comment about wildcards, regular expressions, CSS, XPath, etc., it occurred to me that there's another reasonable option, if you decide you don't like >.

How about // as XPath uses?

It's not quite as concise as >, but it might appeal to your users. It's better, I think, than any of the longer, more explicit syntaxes I've been able to come up with, like:

• ancestor/.../search folder
• ancestor/**/search folder

You probably should NOT use:

• ancestor/*/search folder

That looks too much like it requires ancestor to be exactly a grandparent, but allows any name for parent.  That's what it mean, for example on a Mac/Linux/Unix file pathname.

Anyhow, I think > and // are both good choices.  Use whichever makes more sense to you.

--Fred

Fred Stluka -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates.

[RealRaven2000]

Actually using // is technically difficult and looks a little wonky. Let's concentrate on giving contextual help in the "legacy" way. (Future web extensions still don't support toolbars as was reiterated to me this week, but John suggested something in the chat, even though it is early days) - they allow a "browser action button" which is a single extension defined button in the top right of the toolbar.

Example for a browser action button:

(This was part of an example code John gave to me to check for Add-on updates, see also issue #165)

[RealRaven2000]

Edit: I meant issue #165 (QuickFolders doesn't auto-update) it's an interesting point; I am working on some code that checks for updates to be able to prompt the user to update when they need new permissions to do so.

[RealRaven2000]

I almost missed this, definitely using the word "type" is good for this use case as we normally would us the keyboard (not sure if I even support pasting a search string, I need to test that) - and we used the term "type" a lot in the discussion so that's a good measure for it being useful here.

Good point! Maybe use the word "type" instead of "enter"? I tend to use use "enter" in such situations because the word "type" is more specific. It implies that you have to manually type in the text. Can't cut/paste it from somewhere else. In my mind, "enter" is less specific. It means you can type it OR cut/paste it. But again, I realize that I'm applying very specific programmer meanings to the words. Whatever Axel chooses, to suit his target audience, is fine with me.

[fredstluka]

Axel,

definitely using the word "type" is good for this use case

Sounds good to me.

(not sure if I even support pasting a search string, I need to test that)

Paste DOES work on macOS 11.1, Thunderbird 78.11.0 (64-bit), QuickFolders 5.5.2.

FYI, --Fred

Fred Stluka -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates.

[RealRaven2000]

I made a prototype of the search help popup using some of the layout from this example https://codepen.io/imprakash/pen/GgNMXO

This is what it looks like right now - after clicking the (?) :

In order to position the panel uses a container that covers the complete UI of Thunderbird (at the moment) - so you have to close the popup to continue working. However you can start typing into the search box as the keyboard listener isn't affected, only clicking into the interface. (I will probably handle the ESC key to close the popup as well.

I was thinking of aligning it left to the search box (still sitting on the fence on that one) - ideally the help panel would move to the right of the search results menu, but that's kind of tricky to implement.

Here is the first test version - contents are still subject to change (and localisation), but hopefully it's already useful in it's original form:

QuickFolders-wx-5.6pre234.zip

[RealRaven2000]

Nice to have: some sort of "accordion" mechanism in the list that can expand and show examples. Maybe something for the next version as it's quite a bit of work both design wise and for localisation. Should the heading read "Help for quickMove / quickJump" ?

[RealRaven2000]

Added some more info on what characters are regarded as word boundaries:

QuickFolders-wx-5.6pre242.zip

[RealRaven2000]

Added more help text and improved the look of the panel:

QuickFolders-wx-5.6pre250.zip

pretty happy with the wording in here. If you have any improvements please tell before I start the translation process.