Created an attachment (id=8107) [details]
Preferences for listing search results in Nostalgy

Copied from bug 26071 as new bug (from Start to Stop) - New below:

- - - Start - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I used QuickFolders functions "move to" "copy to" and "go to" for some time now
and it worked really perfect! 
Thank you for this.

Nevertheless I'm missing one thing wich was very helpful for me in Nostalgy:
If I want to move an e-mail to a subfolder named "2015" e.g. but I don't know
the name exactly and therefore search its parent named "archive" there will be
shown  path and / or name (depending on choice in preferences) of the parent
only but not the names of subfolders. That is what I am missing very often -
even if then a long list of folders might be shown.

Is there a chance to put an option to preferences?

------- Comment #8 From Axel Grude 2015-10-04 10:39:49 [reply] -------

(In reply to comment #7)
> I used QuickFolders functions "move to" "copy to" and "go to" for some time now
> and it worked really perfect! 
> Thank you for this.
> 
> Nevertheless I'm missing one thing wich was very helpful for me in Nostalgy:
> If I want to move an e-mail to a subfolder named "2015" e.g. but I don't know
> the name exactly and therefore search its parent named "archive" there will be
> shown  path and / or name (depending on choice in preferences) of the parent
> only but not the names of subfolders. That is what I am missing very often -
> even if then a long list of folders might be shown.
> 
> Is there a chance to put an option to preferences?
> 

I think it could be done, it just might slow down operation. In any you please
case raise a fresh bug on it?

I would suggest instead of listing candidates + all possible subfolders in one
long flat list (is this what Nostalgy does?) it would be good to have a tree
node arrow ► and then potentially only show 1st or 2nd level children,
(similar to the behavior of the recent folders list). It would be slightly more
awkward from navigation POV as we would need arrow down and arrow right, but
you would probably learn the names of the important subfolders quickly if you
had to do it more often.

One problem with features that are "More powerful" for one set of tasks is that
they often are seen as "cluttery" for others. But let's discuss on the new bug.

------- Comment #9 From Axel Grude 2015-10-04 10:42:57 [reply] -------

(In reply to comment #8)
> (In reply to comment #7)
> > 
> > Nevertheless I'm missing one thing wich was very helpful for me in Nostalgy:
> > If I want to move an e-mail to a subfolder named "2015" e.g. but I don't know
> > the name exactly and therefore search its parent named "archive" there will be

- also one more thing, the name matching only matches the start of words in the
folder when you enter 2 letters, from 3 letters on it will match the string
"within", so if you have a folder called

letters2015

it will be shown as soon as you type "201". I am avoiding showing it when you
only type "20" as I want to keep the results as short + quick as possible.
Again, that sort of search behavior is open for discussion (and maybe make it
more flexible).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - Stop - - -


NEW:
In Nostalgy the search happens in the full path - and the results have been
shown fast but sometimes in one very long list indeed. But the function to
select the number of the last recent folders was very helpful than, sometimes
other options there too.
I like your suggestion Alex, that with the tree nodes. Maybe one could select
how deep the subfolders are shown? So everybody could influence the speed of
showing the list.
Might this be an option?

Renamed the bug.

Just to understand the requirements first of all

You know the name of the parent folder (and may know or recognize the name of
the "child" folder that you are actually looking for). This would mean entering
the parent folder name (e.g. "archive") and you would get either of:

1) the parent name and a way to expand into its direct children

2) all child folders underneath the parent with in the list.

In order not to slow down (and unnecessarily blow up the search results) we
could compromise by accepting a special character (Let's say, forward slash
"/") after the "parent" name:

e.g. 
"archive/"

this could be taken as a sign to expand child (or all descendant) folders of
any folder named archive. Alternatively (to save time one could allow entering
the first n (say 3 minimum) characters followed by "*", such as "arc*" as a
sign that we are looking for all subfolders for any folder starting with these
letters.

I think this might be a good compromise on speed vs ease of use? Please think
it through with a view on the examples where you would like to use it and how
much typing / previous knowledge of your  folder structure this would be
require.

A "nice to have" would be:

arc*/2015
where arc* is the start of the parent folder and 2015 partially matched any
subfolder. Not too easy to implement though.

There is not so much to think about: That is a good suggestion!
Both ways would work but the second one would be faster: e.g. "arc*"

And an additional idea:
You already programmed the recent folders. Couldn't you show them if one opens
/ jumps to the search field below thies field and than after input attached
below the list of search results for example? So one could reach this folders
by cursor too.
But anyway I have now idea what great deal of work this would mean for you and
if anyone else is interested in this feature too... I'm just thinking that
anyone else needs this very urgent ;-)

(In reply to comment #2)

> You already programmed the recent folders. Couldn't you show them if one opens
> / jumps to the search field below this field and than after input attached
> below the list of search results for example? So one could reach this folders
> by cursor too.

I don't quite understand to be honest. If you use quickJump to go to any folder
of course that folder will show up on the Recent Folders list. Anything that
receives new mail or is jumped into is "timestamped" and thus bubbles up to the
top of the recent folders list. (Hope I understood you correctly)

Sorry, right you are - it is difficult to explain for me: 

Using quickJump: Exactly that moment one jumps to the search field the recent
folders appear at the lower edge (maybe the upper edge) of the search field and
one could move the cursor with the arrow keys! directly there. 
In other words: Using quickJump I have the list of results AND the recent
folders right at hand than.
Could I explain it this time? I hope not to make it worse...

(In reply to comment #4)
> Sorry, right you are - it is difficult to explain for me: 
> 
> Using quickJump: Exactly that moment one jumps to the search field the recent
> folders appear at the lower edge (maybe the upper edge) of the search field and
> one could move the cursor with the arrow keys! directly there. 
> In other words: Using quickJump I have the list of results AND the recent
> folders right at hand than.
> Could I explain it this time? I hope not to make it worse...
> 

I think I understand. Now I want to avoid showing a very long list (e.g. recent
folders and search results combined) and I assume you are using the keyboard
shortcut (Shift+J). It would be possible to pop up the recent folders menu
_before_ the first letter is typed. Once the user starts typing, the results
are shown as normal. 

I might try making some prototypes on this as there is definitely an argument
that a quick "Jump" feature could be combined with recent folders. There might
be some inconsistency in the drag + drop case, which is supposed to only make
the textbox visible and put in keyboard focus to start typing. For the moment,
let's concentrate on this feature (expanding search results to child folders)
and maybe create a separate bug on your other suggestion later - having
multiple changes in the same bug usually gets messy.

Wonderful that my explanation helped now :-)
Your suggestion sounds good. This could be a good solution. Thanks.

Created an attachment (id=8108) [details]
example screenshot - parent search

Here is the behavior of the patch, test case:

searching for the folder QF-bugs which is in the tree below

Addons
Addons / QuickFolders
Addons / QuickFolders / QF-bugs

We know the (grand)parent is Addons, and there is a bugs folder for the
QuickFolders addon further down (not necessarily a direct child of Addons)

starting to enter Ad brings up our Addons folder, so we decide to go for
children by pressing '/':

(1) Ad/
    For simplicity's sake I am assuming you are only interested in direct
children of the parent folders starting  with Ad (e.g. Addons/QuickFolders)
etc. the list is potentially still long
(2) Ad/q
    The search algorithm will now look at all child folders down to a hierarchy
level of N  (default is 2, which means grandchildren) by matching folders
starting with q
(2) Ad/qf
    Same as above, for folders starting with qf
(3) Ad/qfb
    Same as above, for folders _containing_ the string qfb

N levels: the maximum level of searched parents can be configured via the
config setting
extensions.quickfolders.premium.findFolder.maxParentLevel
which can be configured via right-clicking the quickJump option checkbox in
QuickFolders Options > General > Main Toolbar Elements
Default is 2 (Grandchildren)

Created an attachment (id=8109) [details]
4.2 pre 106

Test Version. Enjoy!

Additional Comment:

There is a slight problem with the quickJump's default behavior of
"auto-jumping" to a folder as soon as you enter a unique folder name
completely.

e.g. if there is only one folder that is exactly named "Addons" and I enter the
string: 

addons

quickJump will automatically jump to the folder without waiting for return.
This would prevent me from entering 

addons/

in order to investigate its subfolders. Workaround, enter the name before /
incompletely or enter  / first and then go back 1 cursor to enter the name

add/

or
/
a/
ad/
add/
...
addons/

I might consider allowing to enter the slash as _first_ character and
automatically move it to the end when the next character is entered.

Created an attachment (id=8110) [details]
example for child in-string searching 

here is another example for searching a string (>2 characters) within all child
folders:

quick/view

searches for any folder which contains the substring "view" and has a
[grand]parent folder starting with "quick"

I installed the test version:
- It feels a little unfamiliar by now ;-)
- Child in-string serch seems to be a good functionalty
I'll work with it for the next days and see what happens :-)

Released in version 4.2.2, 20/11/2015