Any way to create a compound (flag) search preserving the tree structure? Or in tree?

[Spliff]

Well, I did do something for me, from csv export, and could do it even better since "individual", but it's perfect to be standardized as well:

My proposition had been, be a "project" sub-tree somewhere in your full-tree, the project title then being regarded as "level 0". Below, you have level 1, with some 20, 30 bold titles (bold flag, I use yellow for that since yellow isn't readable anyway), for the project's main titles. On level 2, you have possibly 100 or 200 level 2 project titles, but spread over the 20, 30 level-1, main, titles, e.g. level 1 title #1 has 15 level-2 titles, level 1 title #2 has 20 level-2 titles, and so on.

Then, I said, filtering is about de-cluttering, so your filter will show your project's level 1 titles, but NOT also the many level 2 titles; it will show the level 1 titles in order to (not very precisely, but sufficiently precisely) "SITUATE" the CORE info of your filter: special flags, of one, two or several kinds.

As a user, you will want to see those, with just the "necessary" "situational" info provided by the level 1 titles, and since I did it for me, it occurred to me that I could do it even MUCH better: from the level 2 titles, I just show the "needed" ones; I automate this of course.

I other words, my filter shows the level 1 titles, the special flags, and any level 2 title which is followed by 1 or several special flagged items, so in other words, any level 2 title which does NOT serve to precisely "situate" any special flag, is automatically hidden., and that thus goes for 90 p.c. of them; also, any other flag, and any no-flag, is hidden of course.

It's obvious that you as UR's developer could also do this as fine-grained.

I have a little list of targets, let's say targets := "A,U,T"
(B = bold does not appear here, since it's not a target, see below)
(All my flags have 1-char names; the ORDER here: A then U then T specifies the additional tabs = indentation levels for the flag in question, see below)

I then run a loop for every one of my csv output lines (put from file into clipboard, I then run the loop within the clipboard), in case for retrieving the current line for my target file (i.e. I write the lines to be retrieved to a target file (in fact, first into some var, which then will be normalized (double and more double quotes, etc) and written to file).

line without flag (i.e. with no flag): next (skip)

line with flag b (bold) AND indentlevel 1: write (no indentation)

line with flag b (bold) AND indentlevel 2: store in var b2 (replace in case)

(You might have other or no flags on level 1 and/or 2, as "siblings" of these flag-b items: they are skipped by the rule above (noflag) of below (other-flag))

line with flag in targets-lists: fetch curr content from var b2 > write b2 line (indent 1 tab) IF there was content > empty var b2, write target-flag-line (indentation min. 3 tabs, see below)

line with other flag: next (skip: this is even the more or less DEFAULT behavior in filtering)

I thus get:

no indent: bold level 1 titles (outer skeleton)

with 1 indent: bold level 2 titles IF they are title to one or several target lines:
A with 3 indents, U with 4 indents, T with 5 indents, etc (see above)

Thus, I have the skeleton at the left, with its second level just where "applicable" (i.e. where the level-2 line is "needed" as a title for 1 or more targets), and multiple targets but of the SAME flag, SHARE the same indentation level, AND I can determine their "indent order" by changing their position within the "targets" list.

You, as the developer, can provide the same, perfect schema: We just would need have to accept a "convention" that any project's (= any sub tree to then to be filtered this way, or even the source item) first two titling levels (-1 under 0, and -2 under 0) will have to be flagged "B" or "Bold"; obviously, users could use full-written out flag names if they insist, they will just have to make lots more of my typing, since a targets list "A,U,T" is typed in a breeze, whilst perhaps 60, 70 characters are not.

Btw, it took me 3 minutes of hard thinking, how to put in the level-2 lines whenever needed, and only then, but as you can see, then the implementation of it was blunt easy. And you'll get all the level-2 titles you would want, and none of the unwanted ones, according to your specific target-flags view(s).


On the developer's side, this filtering would not be entirely by flags-only, since for the "B" flag (or the flag of which the name starts with "B"), the indentation level also would come into play, but that's easy; for me it was the reason why my csv export not only retrieved the flag, but also the indentation level; note that the NEW indentation levels, in the filtered view, do NOT correspond to the original ones, except for B-level 1 (which becomes no tab) and B-level 2 (which becomes indented by 1 tab).


And MI (now "App": https://forums.myinfoapp.com/viewtopic.php?t=8262 ) is a joke, not even formatted import does seem possible, and the developer gives a crack (it seems he adopted TypeDown or what it's called, hence "App"), and anyway, he's too busy counting the money (since in his country, the dollar is worth tenfold: American developers can only dream of such returns' value. On the other hand though, I would be interested in knowing how the developers of MI(A), RN, MB (all SQLite-backed) do the necessary code and / or tables, in order to get their search results as UR just gets, correctly, its exports.