FWIW, to me it appears like the listed operator cannot be re-used in the run for some reason, even on a different parameter or different field. Yet by itself just once, combined with tag does work. I made my.field and my.field2 with combinations of A, B, C and X, Y, Z respectively and put alpha, beta, gamma in tags, and combining tag operator with listed works fine. And tag filter intersection seems to work as expected: [tag[alpha]tag[gamma]]
Perhaps the clunky original plan of prefixing tags for the possible values of each field may have to be what I resort to. e.g. [tag[name-some name]tag[structure-some structure]tag[context-some context]] On Sunday, September 27, 2020 at 6:50:46 PM UTC-5 Cade Roux wrote: > I see what you are saying, but I thought it was starting with a default > [all[]] operator. I even tried putting an explicit [all[]] operator on the > front. > > Thanks, > > Cade > > On Saturday, September 26, 2020 at 11:37:23 AM UTC-5 [email protected] > wrote: > >> Hi Cade, >> >> you are understanding the mathematical "idea" of intersection correct BUT >> you are telling TW to throw away everyting that your first run outputted >> when you are using filter-operators that throw away the input (stated as >> "input ignored" in the filter operator) in subsequent runs, as *[A]* and >> *[C]* do. See also: https://tiddlywiki.com/#title%20Operator. >> >> What you actually get is everything that lists *C* in your first <$list> >> and *A* in your second. >> >> Regards, >> Mirko >> >> Am Samstag, 26. September 2020 17:56:02 UTC+2 schrieb Cade Roux: >>> >>> Thanks, I have started using a field and I am struggling with list >>> intersections, i.e. lists of items that are tagged both A and C: >>> >>> I thought these would be the intersection and should be equivalent: >>> >>> <$list filter="[[A]listed[my.field]] +[[C]listed[my.field]]" /> >>> <$list filter="[[C]listed[my.field]] +[[A]listed[my.field]]" /> >>> >>> But not only are they not equivalent, they are not correct lists: >>> >>> [image: Screenshot 2020-09-26 105510.png] >>> >>> What am I not understanding correctly about the filter intersections? >>> >>> Thanks, >>> >>> Cade >>> >>> On Saturday, September 26, 2020 at 1:03:00 AM UTC-5 TW Tones wrote: >>> >>>> Cade, >>>> >>>> As far as I know Gentags is the state of the art for a plugin giving >>>> you alternative tag fields. >>>> >>>> Just keep in mind tags are a solution built into the core. >>>> >>>> - I for one avoid them to keep them free for ad hoc tagging. >>>> - Instead I tend to use my own fields and list fields that in many >>>> ways work not unlike tags if you want them to. >>>> - See listops and other operators and widgets. >>>> - Avoid the use of prefixes on titles, including tag names where >>>> practical otherwise you will find you need to parse the title to >>>> extract >>>> info. >>>> >>>> >>>> For a small or for purpose wiki do what you want with the tags and >>>> prefixed titles, its only when you transfer tiddlers or grow wikis it may >>>> become a problem. >>>> >>>> Regards >>>> Tony >>>> >>>> On Saturday, 26 September 2020 04:48:59 UTC+10, Cade Roux wrote: >>>>> >>>>> I find myself looking to use this concept in my data mart data >>>>> dictionary/user manual, as I want to have three types of tags for one set >>>>> of generated tiddlers and three types of tags for another set of >>>>> generated >>>>> tiddlers and putting a prefix on each set and throwing them into tags >>>>> field >>>>> is kind of unwieldy and the filters will be really awkward. >>>>> >>>>> Is https://ooktech.com/jed/ExampleWikis/GenericTagFields/ this the >>>>> latest thinking on that or is there another plugin I should be looking at >>>>> (or something that has made it to core? >>>>> >>>>> Thanks, >>>>> >>>>> Cade >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/144f4966-c371-4623-9c54-06d814a639ban%40googlegroups.com.
