[Spliff]

Since I only know my 5 systems (PC 1 before clean re-install and after*, PC 2 before clean re-install and after*, stick*; *=here at least, the thread-3038 data obviously is the "factory" one, cf. the "Trial" in the above screenshots' caption), I can't speak for other UR users' systems here, so with this reservation:

Before, control-end systematically (?) went to the very LAST row-AND-column (= "Value", so to the very last value of them all), then "typing" (even by macro, i.e. without previous F2) started to change the "Value"'s string value; that's why in the other thread, I suggested to put string values within the very LAST row of Advanced Search.

Now, with your implementation of my suggestion of some Discard / "Exclude" (yours is the better wording indeed) column, whilst I had had in mind "Exclude" as the very FIRST column (i.e. even before "Relationship"; but without specifying that, I admit), you added that column as very last one, so quick "value" input is excluded now, the user or macro have to fiddle around with navigation within the AS rows / columns, beyond a simple control-end, and, worse,

sometimes, the focus in the AS grid is STUCK within "Item/Attribute" drop-down, and then, NO key navigation whatsoever (and with any modifier key) will LEAVE that drop-down, and, for example, both "up" and "down", AND "left" and "right" navigate up and down within that drop-down's entries, whilst at least "left" and "right" would be expected to LEAVE that drop-down, and set focus to "Relationship" or "No", respectively, i.e. go to the adjacent column. (From one AS to the next, sometimes, the new focus is where it was placed on leaving the previous AS, but more often than not, it's re-set on the Item/Attribute column, and then, the errance within the drop-down starts...

This makes AS macros unreliable since the macro "thinks" it's in the grid's intended target column/row, while in fact erring within the Item/Attribute drop-down, and the user has no other way than to use their mouse, in order to navigate off that drop-down.


As for (and always speaking of my 5 systems only) the "Vapor-Func" (OR, *, ?, [...]) described above, to resume:

Even * is unreliable, sometimes it works, but triggering the switch AND phrase search, then again not, seems to depend not only on the place of the * but also on the search terms, so it's not usable, so none of them all work:

For OR searches, I need multiple rows in AS (with those new additional problems described here; I'll have to go back to a UR version before even Feb, 2024 (since not even the March version, but also the Feb version already have the "Exclude" column, complicating things);

ditto for tag searches, only xab (with x meaning, "it's a tag", a being the category, b being the value) works, but works indeed;

as said, implicit AND works fine, so I can put several such tags into the items, or rather into the titles, since that way, I always see them, i.e. know any item's tags without searching, and then some xab xch xgj (even Quick) search (implicit AND) will work, whilst for xab OR xac OR xah, I need an AS grid with 3 rows, so I make several ASs, with 2 OR rows, 3 OR rows, etc., and IF I hold it all within the very same indentation level, even tree order is preserved, so that can I work from within the search results, as I would otherwise do from within the Data Explorer (which becomes unrealistic by experience, considering that filtering (in tree order) is necessary, but that, given the fact that any item just can bear one flag, but several tags, whilst Data Explorer filtering is just possible by flags, not also by tags: thus, working from within the search result grid is necessary BUT doable indeed - just the practical use of the AS grid, again and again, doesn't come really that handy, to put it as "light" as it gets.

MyInfo(App)'s search input field, together with its what you might call "scope codes", and with its (expected, and working) parentheses to group when necessary, obviously are the way to go, since that's the nearest thing to the target SQL "select" code, AND slight changes / variations (which are complicated fiddling around with the AS grid in UR in many cases) are done almost immediately, be it manually by the user, or then by some macro input into that input field.

I admit that UR's input field, together with working OR/?/[...] (i.e. if those ain't Vapor-Funcs as in my 5 systems), is not that bad to begin with, but leaves out any "more-than-just-one-scope" which then need the AS grid... which can't be regarded as "user-friendly" as it is.

This is NOT to advertise MI/MIA here - its search results do NOT respect tree order (and miss most of UR's sort variants) -, so it's questionable if MI's better search input (!) will really be so much more valuable in the end, given its search output (!), but its "tree filter" (by strings = tag or any other word-start-string), is infinitely more valuable than UR's "tree filter" (by flags).

Thus, copying that functionality from the competitor would certainly be UR's most important enhancement in years, and seems to be doable:

Tree order (as in UR for tree filtering) is respected (obviously)
Find-as-you-type, i.e. "live" display of the results
space is "AND"
NO */?/etc
NO sub-strings, just word-start-strings (but not necessarily title-start-strings, and btw: otherwise no implicit AND would be possible), i.e. x finds xa, xar, etc., but e.g. ar will not find xar

JUST for titles, and that makes it possibly very much easier than with "strings-from-everywhere", since the titles are listed in traditional sql tables (i.e. no fts problems), can be indexed accordingly, and UR currently IS able to respect the tree order, by filtering by flags, here in the tree, so the same should be possible with title string bits.

AND, as said before, it should be done in a flat list, but without discarding deeper-down items (i.e. parent items may, or may not, fulfill the condition(s).


Information management being about information retrieval in the end, the most perfect retrieval possible should be the object.

And yes, the ostentatious "lack" of interest (or better: so they insist on simulating) into all these matters, from UR co-users, is so much de-motivating - why should they be given anything then they don't pay extra for, right?! - that I can only qualify it as "appalling" indeed... which spares me to have to use that nasty "pearls before ..." expression, yeah.


ADD-ON:

To clarify: 20 flags seems "not too bad", the number 20 divided by 20 "values"... of the SAME category, but once you divide that number by several (!) categories (!), i.e. color, italics, bold, underline, then combine those (e.g. bold instead of regular for one category, different values then by different colors; another category by italics, combined with the aforementioned categories, by regular/bold, by color for the category represented by colors, and so on), you find yourself with "almost nothing", and then you have to renounce on categories, just have enough possible values-in-all, i.e. 20, to combine two categories, one of the two with a strict minimum of possible values; thus, for categories asking for many values, or even for sub-categories, you are forced to resort to tagging by text-tags... and that will set you back to Search, forces you to LEAVE the "Data Explorer", and then, Search's functionality's problems get into your, the user's way... (That being said, just formatting plus colors for filtering bear an inherent number limit, different formats not being available in number, and colors not being discernable in big numbers by the eye... whilst (additional) text-tags (as explained above) don't come with such bounds but with virtually no number restrictions; thus for more detailed filtering, beyond very basic filtering for just one category, they are the better solution to begin with, or in other words, sharply multiplying the number of flags instead wouldn't have been but a pis-aller anyway. Oh, and I should have made this clear indeed: MI's tree filtering by text-tags (=as many such tags as you need), whilst being much better than UR's tree filtering by flags (just ONE flag possible per item, and just up to 20 all combinations combined), because of its lacking "OR" (at least), isn't that formidable in the end, so "just copying" the MI func couldn't then, unfortunately, be considered "state of the art" yet, and I think it's better that I say so myself, instead of blatantly inviting to some, "and when that's done, you'll continue to complain", unavoidable otherwise:

At the end of the day, working on a really good Search functionality would be so much more worthwhile / beneficial:
- (Alternative) Input by input field, with e.g.: t:some for title, c:some for content, e:some or just some for everywhere, and so on (=scope), parentheses just like in SQL (i.e. the SQL target string anyway)
- Tree preservation upon demand (= by option) and, in case, by re-ordering after the search if it's really that much more complicated to do from search start - from the NON-observation of tree order, within the search results from MI, RN (RightNote) AND UR, I infer that all PIMs have adopted the Adjacency List Model in its most basic flavor (whilst UR's items' titles are stored in three different locations, though: so much for strict redundancy avoidance), and that makes me think that even with some minor ALM enhancement (lots of such ALM-to-"Common Table" extension examples being available in the web), i.e. one with not-too-much additional "write" tasks, already could be some BIG help in refining the Search?

Also, let's face it: On the "Mac" side, tools with "Search Results with the (first-per-item) relevant paragraph" are available; RN offers "n words (!) before and/or m words behind the search term", which makes the results more or less unreadable, since the n before and/or the m before is always much too few or much too many, and I have not found any word wrap, so, and...

to share at least immediately constructive idea here - goodwill! - UR users are invited to put - and, if necessary, even to copy! - the core info (incl. text-tags if they don't prefer to put them systematically into the titles) of any relevant (!) item into the very first paragraph, then browsing through the search results (by up and down) will present that core info much faster, than by having to then, one-by-one for (almost) every "find", SCROLL to the core parts, or rather, those parts where the search string(s) are to be found; I suppose it might be possible though to introduce automatic scroll up to the first "find" in UR instead (i.e. screen display would start with the start of the paragraph which contains the "find"), upon option (i.e. of just highlighting the finds)? (Alternatively, the user might use a big screen, with full-height content pane, AND and large search results pane on its side, so as to hopefully see the relevant parts even without having them on top and/or having to scroll down to them - the success of this strategy obviously depends on the user's average item text length...)

And the user might also display the "Item Text" column, since then, a mouse-over will - fast! - display the "full" text (i.e. as far as there is room for it) within some fly-over pane, albeit in a quite tiny font size, and without formatting, the latter being perfectly understandable since obviously, that "quick-n-dirty" text preview is retrieved directly from the sql table column... which then should make it even less helpful when you store the plaintext of your items in all-lowercase (writing from memory here, not having tried out recently) - be that as it might, font resizing by user setting should be easy to implement, to make this goody finally worthwhile, but many user will probably not even have discovered it in its current form? So they're informed now, but as said, the kind / lack of "interaction" with UR co-users here makes it ultra-difficult to consider them "fellow UR users", which obviously would be the ideal.


Oh, and - OT here - I "upped" my "move-to" script by (after the obligatory ^x, obviously, then) first inserting a {down}, then only have it make the navigation to the target(s) (if there are intermediate targets, too, you can count those, then adjust the number of necessary "Go - Go back"s accordingly), then do the ^v, and then do (at least one) GoBack (shortcut at your leisure), and, heureka, you can do other moves from where you left before the current one; the problem here being that this just works if you do the moves one-by-one, even when they go to the very same target, OR if at least the very last one of the items you will have selected for moving, is not immediately situated above another item, to be moved (and thus, if you move some "block", pay attention that you select the "bottom" item as last one), since otherwise, your "GoBack"(s) will stay within the target area, not go back to the "area of origin" (similar if you send an {up} instead of the down-key) - such being the sudden problems you encounter once you try to put some "outliner" to "power use"... (And, think on it: even knowing the number of the selected items - which can programmatically be retrieved indeed: it's an element of "window text" in case -, will not help since the {down} (similar for {up}) will not work from the visually-"last" item, but from the last-selected one, and if that's within a block, contiguous or not, you'll end up "somewhere"; ditto for copying items, obviously.) - In other words: From the "outside", "only so much"* can be done, at the end of the day, whilst constant optimization of code can "do it all", and this example is just a blatantly simple one... (*=meaning here: if you remember to select the "bottom" of several selected item last, it works as expected, except of course if you work from end-of-tree, but then, a simple {end} after the move will do) - You see here that co-users might have gotten lots of additional goodies if they had made just and strictly even minimal efforts onto what you might call "collaboration" (and just another example: within "global text replace", you must insert some "trick" at some position of recurring part of the script, and then, global replace "from the outside" works fine, but nada... not even one single "thank you", let alone adding / sharing your ideas, hints: nada: Third-party UR users, you call that "constructive"? Wanna make me laugh? ;-) (And when then, on top of that, I pile up lots of problems with the software I can't resolve, for my own needs, I'm more than just fed-up... understandably, I might dare say.)