Keyboard navigation in tree hampered by including items above current item

[Spliff]

Applications with treeviews or listviews generally come with a quicksearch, i.e. when that pane has the focus, the user enters one or several characters, and the underlying code selects the first first entry starting with that character(s).

a) Some such applications start that "search" from the currently-selected item - if the user wants to start it "from top", they have first to press {home} to "go" there.

b) Others present an option to the user, e.g. FreeCommander's : Settings - Quick search - Start quick search from top Yes/No (by checkbox); problem is, they don't also offer that toggle by shortcut, and so, for many such navigational needs, the setting is set to the "wrong" option, whilst changing that setting is very unwieldy.

c) Only very few applications start that "quicksearch" from top - since that's, and by far, the worst solution of them all -, and very unfortunately, UR is among them.

The implications of this policy are dramatic: Let's imagine you "quicksearch", in level 1, for some "a", and let's imagine that - from top: and for level 1, that's even the most practical way to implement it - will even select then the level1 entry asomething.

Then, you expand that entry, since your real "target" is on level 2 or even level 3 (I know about "favorites", but I'm speaking of general navigational tasks here, to a multitude of target items, constantly changing):

Here, ANY, EVERY user would want their next navigational character entry to "stay" within the now "current" level, i.e. their "b" should select the "next" bsomething, and that's the first "hit" within the siblings "children" = level 2, of that, now expanded, level 1 "a" hit -

Or then, if that's not a flat list, since one or some of the "children" on level 3 is / are also visible (i.e. some of the level 2 siblings is expanded, the first "b" hit there should be selected:

i.e. that's the decision between
- strictly next sibling (= same level), and
- next entry (regardless of possible further "indentation").

Neither is possible in UR if there is a "hit" above all those, nearest to the root item (level 1), and it's obvious that there is no UR user who doesn't encounter this a problem, again and again, multiple times a day, or then, they will already have shifted to not trigger that "quicksearch" anymore in such situations (i.e. except in level 1, and hoping level 1 is more or less collapsed.

(I also know about Options - Trees - "Collapse sibs when expanding or going to an item" but that might not be what most users want, since it has lots of other, allegedly unwanted, implications.)

Thus, the minimum solution to the aforementioned problems would be solution a) = start the "quicksearch" at the currently selected item -

But obviously, a MUCH better solution would be b) = toggle between "from top" vs "from current item" (available by shortcut), together with the second alternative = down the tree, regardless of level -

(Since the obviously very best solution, b) and with first alternative (for then the option "from current") = "stay within the current siblings" (i.e. if current is level 1, next hit will be in level 1, too, regardless of possible expansions, ditto for level 2, and so on) might imply considerable coding work? That ideal solution would even be optimized if a simple expansion (i.e. "rightarrow" on the current item) would automatically (if there are children of course) trigger a "downarrow" after expansion, since then, the then-current item would be the first (or only) "child", and the "stay while quicksearch" would automatically search these siblings, without (!) the user having to do "right then down" every time, in order to start further "quicksearches", just the "right" would be sufficient, for every level the user travels down in the hierarchy.)

As said, the current "always from top", with no choice for an alternative, is the worst imaginable implementation of "quicksearch"; please consider.