OMG!
Fantastic work, Kyle, on the weekend, wow! MUCH more than "just 4-5 lines of code", obviously!
(There's a glitch with the "hidden" sets, please see below.)
I made up a little table, for the user better determining what they will prefer, will try with spaces (since tabs would very probably not work; see below).
In different situations, users would like to switch between different sets; perhaps not between all of them, but perhaps between 2, so perhaps, with an upgrade (!=update), it might be possible to switch, by shortcut (toggle?) between (pre-set) two of them?
(Currently, any switch is by registry, so the user has to close down UR (before or after doing the reg change), then re-open UR, but that's without problems:
Win-key, then enter "reg" (always (!) without the ""), enter
there: ^f for "Search", then "Computer\HKEY_CURRENT_USER\SOFTWARE\Kinook Software\Ultra Recall\Options" enter
Then double-click on the hit ("Options" key (, left pane; not on the the key-value ("type", "data"), and in the dialog which opens by that, simply change the numeric value (the necessary "Base: Hex" is already preselected, you enter the number as any digit, e.g. "6").)
Your idea to INCLUDE HIDDEN items (by option) is SPECTACULAR, I've never seen that!
AND you're right to pre-select "8" as default, since that's what most users would expect, from their experience with almost all other software as well as from what they would intuitively select for themselves.
Also, the LOOP when not-successful is more or less expected by users, whilst in (flat) file manager lists, "you" will then quickly be "where you want to go", in many situations, i.e. at the intended hit above (!) the starting-position...
whilst in an outliner tree, strictly technical "looping from above", in many situation, has a very unwanted (!) effect: It throws the user OUT of their "immediate work space", bringing up some "hit" "way off", somewhere several levels above in case, and there, in some totally different area, i.e. this loop then will have totally aleatoric effects.
Thus, the user will be well advised to do "vicinity searches", i.e. starting from current-position, and when they are not sure the target is below that position (since they might have it before their eyes, then no problem), to do such searches then by starting with {leftarrow}, in order to start the search from there.
(I don't know if it would be difficult, technically, thus code-wise, to start any "necessary" loop (i.e. just the loop in case) then from the immediate parent of the item from which the quicksearch had been started? If that's quite easily feasible, I suppose every (!) would then prefer that behavior of 5, 6, 7, 8, over the loop jumping to the source item again.)
Even as it is now, "8" for me is an INCREDIBLE RELIEF, thank you so much, Kyle, I'm eagerly awaiting the next upgrade, two years between seems to be "good for everybody", I think. ;-)
As said / implied, 0/1, 5 and especially 7 (i.e. 8, but including hidden items), if you can bring it to work with not too much fuss, will be a spectacular USP: Already your transclusion implementation is without par, users can then work on any of the (even multiple) occurrences of that cloned, whole sub-tree in case,
they just need to know that when they do manual rearrangements of the child items, etc. within that subtree, they are well-advised to press Shift-F5 afterwards (and in any case before closing the db...), and if they do, there will not be any unwanted "surprises"...
(Perhaps you could automate that "Tree - Refresh All" for taking place "behind the scenes" whenever the user leaves (the current occurrence of) that cloned subtree? Since it might be that users "tried out" that fantastic feature of UR's, then did not the "Refresh", and wen re-opening their db, they discovered their changes had been discarded, then (and by that) erroneously presuming that transclusion (called "linking") in UR wasn't "reliable", when in fact, it perfectly is!)
So, UR is really unique in its power, and even finding hidden items by quicksearch would make it even more outstanding...
This then also includes looping, e.g. (and that's systematic) you have
asome
bsome
csome
which all are parents to subtrees, and all three are collapsed, but before, a had been expanded, b and c not yet.
(I'm certain with this, you know already where the problem lies... ;-) , but to explain for fellow users
You "are at" b, and you enter "xy" (with "7", as said), and in c, there is some xysome, so c should be expanded, and its child item xysome should be selected.
But since c had not been expanded yet, it stays collapsed, and a is expanded, and its xysome is selected; ditto even if xysome is also in b itself (remember "we are" at (collapsed) b when we search for xy): So in this case, even when the intended hit is a direct child item of b, it's not found, but here again, after loop, xy in a found (since a had been expanded before); I also tried with clone items, and it's the same behavior.
All this is "systematic" behavior of "7" and "5", which I then also tried out for this, whilst I admit that I suspect 1 and 0 behave the same way, without having them tried.
Since (also from what you recently said) I suppose that everything which is shown in the Data Explorer, is loaded into work memory (and stays in it for the whole work session (??? So, might it work reliably at least for many hours the same day, for subtrees having (!) been expanded at least once that day? - alleging there is enough work memory (in my case 16gb), so that UR might not be driven to de-load some data again, for space reasons? But it might de-load data after some time, automatically, even within the same session, and even if there is enough work memory?!), but obviously not beyond...
If UR's memory management is predictable after all, i.e. if it does NOT automatically de-load data but if there is not enough space for it (which will not occur then in my scenario and many other users'), the "find even hidden items" sets (0, 1, 5, 7), I would probably stay with "7", since I could expand levels 1 (manually or by macro, according to the situation, and then collapse the whole tree again by UR's shortkey: Tree - Collapse), and that would then also load all items on level 2 (!) into memory, and then, from level 1, all collapsed or some subtrees expanded, as may be determined by my work situation, I would have quicksearch access to everything on level 2, and this would make possible enormously fast navigation, especially for "FILING" from inboxes!!!
So, please, do not take away those sets 0,1, 5, 7, now we (very probably) know why they work as they do, instead of working as we all might have expected beforehand: obviously, they are not "useless", but can come very handy, at least on the (higher-up) tree levels for which the user will have memorized the (main) item names / name-starts.
So, this arises the question if your next upgrade could possibly introduce another command (available by shortcut), or even a setting, specific per db and stored with the db, "pre-load (beyond level 1 also) level 2 into memory upon loading the db"...? This might probably not be too complicated, I suppose? ;-)
It's always a big regret when a BRILLIANT idea gets up the chimney, because some well-hidden (!) precondition isn't met in practice, so we should cling to that chance of quicksearch even finding hidden items, at least for our "very important targets", or then also for use in subtrees deeper-down, here and there; of course "7" e.g. will there then have some really unpredictable behavior, since we wouldn't necessarily be able to memorize what will have been expanded, and what has not been, down there.
But users who then find out they can't live with 7, are free to go back to 8 (e.g.) anytime...! ;-)
(And, as said, looping should, if easily feasible and after some upgrade, remain "somewhere in the vicinity": a restart from the immediate-parent of the unsuccessful search's start-item seems the ideal way to do that, since "drill-down", instead of "going up in the air".)
___________one-char_____one-or-more-chars
children:
just/even____vis/hid______visible/hidden
FROM:
SOURCE:
children:_____4 / 0_______3 / 1
CURRENT:
children:_____6 / 5_______8 / 7
disable: 2