|
My question re framework was because 25 years ago, .Net hadn't been there yet; I hadn't thought of MS tools before .Net; thanks for clarifying!
Sorry, my bad: The "stick version" (= situation e) = a fith one) is as faulty as the (newly and "from scratch") installed version, "new" items created on purpose weren't "found" since they didn't contain "or", as string, so "a or or", being processed in all 5 situations a)...e) as "a AND b AND or", wasn't found, obviously: after hours of trying, unsuccessfully, I then unfortunately tend to make even very stupid mistakes; a good night's sleep afterwards then clears the mind.
Btw, I tried with "dieses" and "jenes" (= "this" and "that", but certain to not introduce a "stop word" problem), and then, neither of the items just containing "dieses" OR "jenes" was listed as a "find", BUT when I then selected either of those two items manually, the "dieses" or "jenes" (in the text = content) was highlighted (which is only expected for search results, not also for the first item the user navigates to, after a search), whatever it was: if I selected the "dieses" item after the search (title = "v1"), "dieses" was highlighted, and if I selected the "jenes" item after the search (title = "v2"), "jenes" was highlighted, and vice versa: highlighted "search find" (but not also appearing within the search results) for the very first item selected after the search, whatever it was.
For a "dies?s" search, or for a "jen?s" search, I get some search results indeed, but with nothing being highlighted, since the whole content of any of those "hits" doesn't contain any string which could be translated to "dies[a-z]s" or "jen[a-z]s", ditto for searches for "dies[a-z]s" > "contains keywords" > LONG "hit" lists which don't make any sense, without any hit, neither placeholder- nor literally-wise, and then, changed to "matches wildcard" manually, no hits anymore - all this with fresh installs, not only after my "adjusting" the UR settings to my wishes.
The next step would obviously be to buy a third W10/11 PC.
(As said, OR works fine by AS in 2 independent rows, and I would have needed the ?-placeholder for "tag-pivoting": sometagA[a-z] being possible by searching for sometagA, but for searching / filtering by sometag[a-z]A I would have needed a "working" ?-placeholder, and, obviously, such "compound" tags would be (=for other UR users; would have been, for me) extremely useful for FILTERING-by-searching.
I then thought I could replace them by TWO tags instead, then searching = filtering for them by implicit AND:
sometag* someothertagA [1]
or
someothertagA sometag* [2]
= instead of
uniquetag?A
that is, and the * assuring the switch to "matches wildcard" will be made (it is made indeed).
Since 1 didn't work, I tried 2 (i.e. the * at the end), and that didn't work either, i.e. correct translation to AS, but no result, and:
When, in AS, I then click on the "Quick" button, I see that the QS search string has been enclosed in double quotes, so it reads now
"someothertagA sometag*"
(for both versions, 1 and 2, i.e. the * being "within" the string, or at the end of the string, does NOT have any implication).
Thus, it's obvious that the code which translates the search string, makes false assumptions, caused by the * here, or then caused by the translation to "matches wildcard", itself (correctly) caused by the *). (When I search for "sometagA someothertagB", it's found, and back to QS, it's without the "", but of course, we're in, and stay in, "contains keywords" then.)
Thus, even * does not work correctly BUT when it's only one single search string, with the * at its end:
sometagA* [that works indeed]
When the two tags are in the same line of the content, i.e. not in different lines, then
sometagA someothertag*
is successful ("matches wildcard" is done, and item is found), but back to QS, it now reads
"sometagA someothertag*" [= phrase search]
whilst (logically then)
someothertag* sometagA
doesn't find the item (which contains sometagA and someothertagB)
since, whilst AS shows, matches wildcard someothertag* sometagA
back-to-QS button brings
"someothertag* sometagA"
adding (unwanted) phrase search to placeholder/ wildcard use again, but possibly treating the * literally here because it's not at the very end of the (as said, unwanted) phrase search;
on the other hand, when I put
someothertag* sometagA
into the item content, into the same line = as "phrase", and expecting that "since" UR treats the * literally, that "phrase" should be found then, AS
matches wildcard someothertag* sometagA
does NOT find anything, albeit, back to QS, the search now reads,
"someothertag* sometagA"
where clicking on "Start" brings "0 matching items", and back to AS, it now reads
matches wildcard "someothertag* sometagA"
and back to QS, it now reads
""someothertag* sometagA""
and with this back-and-forth, I can multiply the "" at will, whilst it has never been intended as a phrase item to begin with!
I hope you can replicate (parts of?) my "a * brings unwanted double quotes (but doesn't treat the * literally anyway, and treats it as placeholder just at the very end of the forced phrase)" problem (which seems to indicate the search string might be processed faultily, internally)?
(Obviously, I closely verified my tag strings, and my search strings, in order to not make any mistake here.)
|