|
( QS/AS being QuickSearch / Advanced Search, respectively, and obviously: )
A)
In practice, it's NOT possible to "flatten" the hierarchy in UR, since:
a) compare this construct:
'a...
____.b...
________Something:
.b has 'a (or more precisely: \'a) in its lineage, and
Something has both \'a... and \.b... in its lineage, and
Something, and also anything within the possible sub-tree of Something, can be found by QS (triggered from 'a... or from .b) Something (with "LS" checked), "LS" being the checkbox "Limit search to selected item in Data Explorer pane", in other words, "Local search", i.e. "just in the current sub-tree";
b) with this construct:
.a - ...
.ab - ...
____Something:
even .ab (which corresponds to above's 'a .b, obviously) does NOT have .a (or then, \.a) in its lineage, all the less so would Something have \.a in its lineage, thus:
triggering, from .a, an "LS" QS search, for .ab - ... or any of .ab -...'s child items (including Something, and any of Something's child items, and so on), would fail; you would have to do a global search instead, triggering lots of unwanted "finds", in case.
Obvious solution to this problem: You build an AS instead (if the * works on your system that is), with:
- item - contains keywords - Something (or whatever string the "target" item may contain, in its title, content, "Notes", etc., anywhere below .ab in general, or below Something in particular)
- AND - Lineage - matches wildcard - \a* (or \ab* if you want to do an even more specific search)
Thus, with strict technical (=indentation-level) hierarchy only, you can avoid AS, whilst with just a "virtual" hierarchy", .a and .a[a-z] being placed onto the same indentation level, you will need the AS... which is a nightmare if you do perhaps hundreds of "searches" (i.e. "greps", filterings) a day (which is my case).
B)
But this "flattening out" the hierarchy in UR would be of interest indeed, considering that:
Whenever you want to [/B]navigate[/B] to some "item" (i.e. some "inter-title", prefixed with some "marker", as the ' and . used above), it's evident that a simple entry .a, or then .ar will be oh so much more "easy" - if those "."-entries are immediately below your source item, i.e. in level 1, than to navigate first to some entry 'a, then to its child item .b (without knowing if item 'a has already been expanded or not)... and then, if you are mistaken of the existence / naming of an item .b "within" parent range 'a, and if some other range 'whatever is expanded at the same time, your macro will "target" the .b... inter-title within, let's say, the 'c... parent range, since your macro will use the in-built tree-navigation, by "targeting" the "very next" .b... item, be that within its intended range 'a..., or then within the 'c... range if that one is expanded, and some .b... item is existant within that range...
And yes, you can then, i.e. "after the facts", trigger a "UR command line" retrieval, and then check if your ".b..." find (or further find below .b...) has a \'a within its lineage, but that costs 1,000 or 1,500 ms more (since your macro will have to retrieve, by clipboard, that "UR command line" first, before being able to analyse it), and this procedere cannot be called "elegant" or "smooth" in any way...
C)
On the other hand, within the file system, such macros are without problems, since in both situations, a) and b), you just work with * (i.e. a*\b*\*/something or then, ab*\*/something) and thus you have free choice between the paradigms "deep" or "flat", and both procedures work fine, by any professional code: I do both, i.e. all four, both in AHK and in Everything, the * being a placeholder for some sub-routine in case but which, on a modern PC, just takes some ms indeed, and NO markers like ' or . being needed, since the \ will lead the code, whilst in a db like UR, the LEVEL is ambiguous, i.c. can not be counted fast by the number of \ within the path, and then, the (navigational, move, copy, link) TARGET is specified by that path, and reached immediately, whilst in a db like UR, by scripting from the outside, it will have to be reached, step-by-step, and time-consuming path verifications being necessary at every such step then.
D)
Thus, yes, in DBs like UR, and especially in such DBs, a "flattened" hierarchy is largely preferable (since it does away with the need for "command line" verification, "is the target .b... really a child item of intermediate target 'a...?", all these not being needed within a file system navigation / move / etc), but, frankly spoken, UR's AS "costs" you several seconds "on top" of what would have been necessary, for every single search, and thus, if there was available some ENHANCED search box, as in MI and other software, and which would allow for entering
l:a* Something [l: = "within lineage", or better: p: for "path"]
or then, if you want it to be more precise:
l:ab* Something
this would not only speed up searching / filtering enormously, but it would also spare you to first navigate to the "parent item" in question, then check the "LS" (see above), but you could trigger this QS (as you could trigger the respective, but enormously time-consuming AS now) from anywhere, and a search "from current item", i.e. within the sub-hierarchy of that current item, could be triggered by:
l: Something
i.e. without placing any value behind the l:
And similar for any other QS:
Kyle, could you please consider such an enhanced Search Box, but with publishing a list of all its codes you consider to implement / use in it, in order for allowing us to have a look upon them, and to give our view?
And yes, such a system would sacrify the possibility for searching for some:some, but then, nobody really would need to search for some:some, except if they had used that string-form for tags, and why couldn't they replace those tags then by some.some indeed?
And yes, the some before the : should be as short as possible (hence my suggestion to publish them here, before implementation, or then, why not invite us to make such list, open to suggestions then, from the current "Item/Attribute" drop-down):
pt:some (always without any space around the ":") would be parent-title:some, and
pt: would be parent-title:current-item's-title, as any empty value after the : would be "current-value" wherever it makes sense.
The necessary "core" code for such a UR Search Revolution had already been implemented, by your transcription from AS Search grid to SQL string, and, frankly, UR's current AS Search grid is a nightmare, costing an additional 5s even when applying a script, and costing minutes for manual AS search: the absence of a FAST entry for the variable part(s) of those "stored searches" being the main problem, the "grouping by indentation instead of by parentheses" being the secondary one...
and the good news is, twofold:
- user's parentheses within the enhanced search box could be transferred 1-by-1 to the sql code (i.e. no additional coding work needed), and
- the current AS grid could be preserved without any additional effort, for people who prefer that, well, "very original" (and very time-consuming), way of searching. ;-)
|