The AS GRID again.
As said, Tree ("Data Explorer") filtering is worth only so much, since can't be done but by the respective flag of the items, and any item can't bear but 0 or 1 flag, not several ones - which is logical, of course.
So I filter by Search Results pane, and work (sic - working on data, in opposite to info gathering) from there, and, as explained, I limit my "Core info" to level 2, put the intertitles into level 1, but replicate those titles in level 2, as very first child item:
root (level 0)
1 (level 1, titles numbered for sorting)
__2 - title 1 again, bolded and as full-title i.e. with meaningful denomination (level 2, remains child 1)
__ some item (level 2 child 2)
__some item (level 2 child 3) ETC ETC
2 (second level1-title)
__2 - that title replicated for level 2 and with full-text-title (stays on child position 1) (bolded)
__some item (level 2)
ETC
Then, as also explained, it's possible to search for any info, within level 2 only, AND to have the intertitling also present within the search results; for this, it's necessary to use AS (i.e. QS is not sufficient); see the screenshot; the name of the search lists the columns to be displayed, and their respective sort order/precedence.
As said above, an organic way to do such a search would be:
Search for: xyz
then the AS grid:
line 1:
OR Notes contain °t (or "Flag is bold"): this for the intertitling
line 2 (indented!):
AND Level is 2
> SQL: (xyz or Notes °t) AND level 2
Thus, the "Search for" input-field would be considered as the very first (and non-indented) row of the grid, so that the current grid row 1 would also get and/or, which would affect its relationship with the "Search for" row.
This would made possible to trigger stored searches, put the (variable, main) string value into the "Search for" field (which already has focus), then enter "Return", and the AS is done.
Contrary to the above, UR's AS grid works this, totally unnatural way:
The "Search for" string is one "AND" part, and the whole grid below it is the other "AND" part of the search:
(Search for string) AND (The total outcome of the Grid)
And thus, in order to put in the string, if that string is not by an additional AND condition, but by an additional OR condition (in one, or as block, the grid is always AND, to "Search for", currently!), the user has to type about 5 times "Tab", in order to get into the grid, then has to navigate, in several steps, to the string value field... whilst the "Search for" field (where the string could have been entered with minimal effort and in a fraction of the time) remains empty: this is aberrant indeed!
Just some days ago, some alleged "review" has been written here,
https://www.outlinersoftware.com/top...-8--new-review , and again, it's said that UR (to which MI is compared for several aspects) was "slow" in comparison...
which obviously is not true BUT the user-software interaction in UR would "MAKE" it "slow", in that sense that this interaction takes much to many steps, for regular, frequent actions which should become easy, "smooth".
In this respect, also in that "review", UR's attributes system is mentioned, and compared to MI's (which has some of that mythical "Ecco" grid (but which does NOT make it possible to enter values into those fields programmatically, but only by selecting the field by mouse-click first (!), and such "reviews" systematically shovel such relevant detail under the carpet...
But fact is - and we discussed this in another thread here, some time ago -, when I want to use a (factory, or user) UR "attribute" for tags or other values, adding / setting / updating that "attribute" is far from easy, since I first have to display the attributes pane, then have to to navigate, deep into the attributes list in there, and that "takes time": too much time indeed, and thus, people say (without ever specifying though), "UR isn't fast enough".
Btw, that's why I now display a 1-line (!) Notes pane, and put my tags into that Notes pane, living with the fact that then sorting (!) by the Notes pane makes sense only for the very first tag in that pane, and thus, for other tags in there, I just can search of course, obviously, and from my experience, that's ok with me: I always put the tag by which I want to sort, as the very first one.
It's the little things that are awkward, e.g. I had to use the Notes pane as "tags pane", since my original idea to use the very first line of the Content pane (i.e. the "Item Text"), then put a blank line after the tags, then start my "regular text", will result in the UR code deleting (!) the blank line, i.e. the two `r`n, ditto for tabs, and so, and put the following text directly after my tags; in order to avoid that, I would have to make a "blank" line, containing 40 or more spaces, in-between my tag line (line 1) and my text begin (line 3), so I chose the Notes pane solution instead.
(As for leading (!) dots and commas to be considered "is a word character", and thus becoming usable as a "tag code" (.tag instead of °tag e.g., for quicker entry and more pleasant visuals), I'm not sure of the coding implications for avoiding problems with trailing . and , as trailing chars, re fts, but, as said there, in MI they are allowed as leading string chars, and correctly filtered by (in the tree, as said).)
Please look into the "'Search for' as part (!) of the AS grid, instead of the grid being a forced additional (="AND") condition for the 'Search for' string" problem: Prove people wrong when they say, "UR is (too) slow"!
.