[Spliff]

After some practical use, I've not been happy with my solution(s) above.


1) Core items (which regularly would be in level 2) > together with the (inter-) titling, in level 1.

The visual aspect (see above) is top-notch indeed (for special use cases that is), and the tree-preserving search results (which exclude further-down level "finds") are satisfying, too; the fact that ALL inter-titling here is just ONE level (whilst ordinarily, they would be spread over 2, 3 levels) also is acceptable in those special use cases.

The problem lies in the navigation, though: Since core items and their "conceptional parents" are at the same level, the icl (item command line) of the former does NOT contain the latter, and that makes navigation cumbersome (but not impossible):

My system relies on markers, so the titles bear not only "bold" flags but also (here) a leading dot, and then, the titles are named in a way that their very first "normal" char (i.e. the one after the dot) is unique in this construction; thus, for navigation (or for moving items), it's possible indeed to go to the root item ({home}), then to send ".f", to go the .f title, then to send "e" to go to the item Esomething below title ".f"; since it's a macro, you would not press 4 keys (home, dot, f, e) but "just" 3: specialkey, f, e - obviously, this macro doesn't really help if again and again, you want to STAY within your current "sub-tree", i.e. within the range of your "current siblings", i.e. those which have the same "parent", ".f" in this example.

If you just press "e" instead, you will probably go to some "e" which, in the tree, is below your current position, below some title "h" in-between; thus, you would want to go to the "parent" item first (i.e. the title "above" your target item: ".f"), then you would want to go to its "child item" "esomething".

In this situation, in a regular construction (fsome or .fsome = level 1, esome = level 2), this would be easy, even without a macro, since you would simply enter {left} = go to parent, e = go to esome = just 2 keys, AND you would not need to first think of "what name is the parent?", whilst in the "everything in level 1" construction, you would have to check or remember the "f" for the "parent", in order to first go to it - and then you will have to work this way all day long in your "everything in the same level" construct.

Thus, this is visually pleasing, and gives the wanted search results, but it's not realistic in real life.

Thus, I have adopted a "more regular" construction, which visually is awful, but which is the only construct you can currently really use if you need tree preservation of the search results:

Root (level 0)
.T (level 1, abbreviated so that it's less awful)
__.Title ".T..." in full string (all these in level 2) (edited)
__Core item
__Another core item
____(on level 3 and deeper down, other items in case, obviously)
__and so on
.A (level 1, abbreviated again)
__.Another title, ".A...", in full string (level 2 again) (edited)
__And your core items here (level 2...)
__etc

In other words, I duplicate the first char of the titles into a higher-up level (level 1), then search for results just in level 2, and get the same search results as before, BUT can now do
- {left} e (2 keys) for getting to item "esome" "within" my current "f" siblings range, and, of course, when I want to go to some item elsewhere, I can do
- specialkey h k (3 keys to go root, then go to .h (for hsome, and make that the first visible item then), then to ksome.

Please note that without the leading .title dots, such a navigation would not be possible but if you systematically collapse anything (UR has a setting for doing this even automatically if your really want to do this), which will seriously hamper your "overall view" though.

(As for the search, see below.)

(EDITED above:
"__.Title ".T..." in full string (all these in level 2) (edited)"
I first had left out the leading dots here, trying to hold it as simple as possible, but that was misleading, since in fact, I replicate the dot:
Since CharSearch navigation is "top-down", the ".A" will be navigated to (level 1), not the .Afulltitlestring (level 2) (ditto for {left} for "go to parent item"), but after that, any "a" will navigate to the very first ASomeItem (item starting with "a"), so it would be misplaced to "sacrifice" the "a" for AFullTitle when replicating the leading dot (necessary for the abbreviated title only), making it .AFullTitle instead, does not do any harm but preserves the possible use of a leading "a" (in this example) for any core item in that "A" title's child items range. Thus, technically, "AFulltitle" (level 2) would be sufficient, but wouldn't be advisable.)


2) The Search Rows

I have explained above why the current AS (advanced search) construction, with "string by input field" plus "AND BLOCK" condition to that string condition is unusable for many real life search tasks, so I suggested, for those situations, to use the very first AS ROW for the string condition, but that would make control-home for first row, then {end} to activate that row's value column:

It's easier to use the very last row instead, since a control-end will automatically activate its value field (in one step, instead of two); also, in my example for the task above (1), compare the two (functionally identically) constructions below: obviously, the second one (in this case at least) is more comprehensive.


3) Currently no "Discard row condition from search"

Whilst the conditions AND and OR are available by drop-down, the NOT condition is available by check-box; what's missing though: a checkbox for quick-n-dirty discarding (!) a row's condition (which obviously is not NOT but "is irrelevant currently"); technically, such a row would not be retrieved while the code behind the AS interface builds the AS's select-string - so technically, the implementation would be easy.

Obviously, this would help for standard ASs with "variants", so that the user would not have to multiply stored ASs but could choose the applicable variant "on-the-spot".


And here now the two screenshots both illustrating 1) and 2), the second one, as explained in 2), obviously being preferable in the situation explained in 1) and possibly even beyond: