Perhaps if you want to see all tags the idea of combinations does not make sense.
Hi @Springer, just a side note: Each $reveal widget creates a DOM node, even when it is not “revealing” and the node is empty/hidden. With the doubly nested $lists and a wiki with a lot of tags that may be a lot of DOM nodes, slowing down the display.
Alternatively, you could use more $lists which do not create DOM nodes when they are empty.
Have a nice day
Yaisog
Hi @Springer,
very cool, thank you! Your are right, your code is less complex than mine. I will definetely use it for my topic.
But sorting by the count is also missing in your example. I would like to list the pairings chronologically by their combination count. The one with the highest on the top and so on. The highest in your picture would be this:
Do you have an solution for this?
Yaisog,
I feared that this kind of solution would be inherently computation-intensive with a large wiki, but I did not realize that the reveal widget is more of a culprit than nested lists.
Now I have at least one rule of thumb in trying to make my solutions less inefficient.
Thanks!
-Springer
Perhaps you don’t really mean “chronologically” (since I’m not sure how a pair of tags would have a time assigned to it, as a pair), but just “sorted according to their combination count”?
Alas, sorting the all-encompassing set of tag-pairs — that is, sorting a set whose members are neither tiddlers nor tags (which TiddlyWiki happily slices, dices, and sorts), but rather all-distinct-pairs-of-tags-that-occur-together-in-at-least-some-tiddlers — is difficult (at least for me!). By the time I can display the list of tag-pairs, I find I’m already relying on a nested structure of simpler lists, and I’m not sure how to extract the pairs themselves as things with “meta-data” (as it were) according to which they can be sorted.
Perhaps someone with a level of skill far greater than mine would be interested. 
Seriously, this more complex task is the kind of coding that someone would deserve to get paid for, imho. 
-Springer
@Springer I was afraid that it would not be so easy to solve. I was hoping that there is some function in tw5 that can solve the problem easily and I just don’t know it. Maybe someone else has an idea. I will continue to try to implement and let you know if I find a solution. If there is no other way i will change to java script.
Thanks for your effort!
@Ransche please make sure you consider my comments here;
Try and think this through, even do a mockup after developing some realistic example data.
@Ransche I also concur with @TW_Tones that it would be helpful to think through your imagined workflow — why you want this tag-intersection data (for every conceivable pair of tags?) and what purpose is served by the sort-by-count-of-tiddlers-at-intersection. With such things in mind, sometimes it turns out that there’s a simpler way to crack that egg, as it were.
Indeed, I would ask whether you’re using tags in the optimal way for your use-case. You might consider intersectional tags, or different fields for different parameters, if you recognize patterns of intersection (place-and-time, agent-and-client, etc.) that are especially typical. … I often use tags until/unless I see the data patterns whereby tags should become field-structures, or where there should be a hierarchy-structure among tags (rather than a flat set of tags), etc.
One thing I could imagine is: using the “crude” solution above to scan for patterns, and setting a threshold (such as intersections with at least 6 tiddlers, or whatever) as an important break-point, so that you can then see all “busy” intersections.
I’ve implemented that busy tag-intersections tiddler at the google-fonts site.
(You may also be interested in the combined tag-filter there, which allows you to peek into any
intersection of tags.)
-Springer
P.S. I’m pretty sure you can accomplish what you’re trying to do – if you’re determined to do that – with a custom macro defining tag-intersections (such that you can then identify features of each intersection). I’m not up for doing it now, but I’m pretty it’s doable without resorting to javascript.
@TW_Tones @Springer Thank you for your effort 
Unfortunately, I am very busy at the moment. I will try to answer you today or tomorrow with a detail description. @Springer I will check out your examples too…
Take your time, I have raised a related question here Find common tag(s) in list from filter, a TiddlyWiki Challenge that may prove interesting.
I have a similar case to display tiddlers with a set of tags.
My literature is tagged several Tag/Domain (e.g. Crop Model, Machine Learning)
Then I develop Doc tiddler (e.g. Crop Model - Machine Learning) for a combination of Domains (e.g. Crop Model and Machine Learning).
Now I want to list all literature tagged with proper domains (e.g. Crop Model and Machine Learning).
My method is attached and is a viewtemplate for tag Doc
$__bangyou_viewtemplate_doc-literature.json (1.4 KB)
This method also applies for any literatures tagged with Descendants which I assume they belong to same topic.
In this case, any literature tagged with Random Forest and Crop Model will list in the Doc tiddler.
My plan is following:
I want to create a tiddlywiki for my wardrobe aims. I want to create an Tiddler with a picture of an outfit I like. After that I want to add tags to this tiddler to classify the different outfit parts.
The tags which are used to classify should have a tags in following format:
A simplified example of the tiddlers could be:
Outfit A
tags:
Type/Trousers/Color/Blue
Type/Trousers/Subclass/Jeans
Type/TShirt/Color/White
Type/TShirt/Subclass/Polo
Type/Belt/Color/Brown
Type/Belt/Subclass/Woven
Outfit B
tags:
Type/Trousers/Color/Grey
Type/Trousers/Subclass/Chino
Type/Shirt/Color/Brown
Type/Shirt/Subclass/Business
Type/Belt/Color/Brown
Type/Belt/Subclass/Plain
Now I want to create a tiddler with a buying list which is sorted by the descripted combination count (in this example “Type/Belt/Color/Brown” has the most combinations). By this list I know which part I should buy next to complete my desire wardrobe.
Another example for a useful tiddler would be one which shows the color which should be combined with another to get the desired wardrobe style.
To list the tiddlers uses Regexes like this:
^Type\/(.*)\/Color\/(.*)$
^Type\/(.*)\/Subclass\/(.*)$
So I don’t want to list all combinations but only the ones that match with a certain regex. This might put the performance concerns into perspective a bit.
Your “busy tag-intersections” is already very close to the solution of my problem. But if there is any possibility to list the combinations sorted by the count, I would prefer this solution. I think if the list will get long the sorted count solution has advantages.
The “Combined Tag Filter” is very cool and I think i will use a modified version of it in my wiki because with this I have the possibility to create outfit quickly. The only thing i would add is again a count after each unselected tag which shows how many outfits are possible with the already selected tags (but that’s another task
)
- Have a look at the various Tag Cloud Solutions
→ which do you mean exactly- I Imagine you want non system tags only
→ I want to filter with the regex formulas- Think about your data, the current tags and ask yourself what is the best way to get an overview and why?
- Sometimes we make these things then don’t use them.
→ For the buying list- There was a tool called x link that helped review tag combinations but you must select which ones are involved.
→ I will have a look, but for my buying list there I do not want to select the tags
For the problem I currently have only the following impractical solution:
For me that looks like “the wrong tool for the task”. … I would go with fields instead of “namespaced” tags.
You could have a field named: x-type with a value eg: Trousers … (type is used by TW)
A second field name: x-color value: blue … (color is used by TW )
subclass : Polo
Eg a filter to list all Polo’s would be [subclass[Polo]] … done.
OR [x-type[Trousers]x-color[blue]] :or[x-color[green]] … would show every thing typed: Trousers and where it’s x-color is green :or any other thing which has a x-color field green
If you want to count your Trousers use: [x-type[Trousers]count[]] … The filters that can be used are so much more flexible
just my thoughts.
This looks like what I would call a compound tag, just as I have posted about avoiding “compound tiddler titles” I advise against this because it forces you to decompose the “compound value” everytime you use it.
All you need is separate tags;
Type Trousers Color Blue
Subclass Jeans TShirt White
Polo Belt Brown Woven
In fact you would only add Trousers / TShirt / Belt - because they are tagged with “Type”.
@TW_Tones But e.g. how can I search all Tiddlers which are included white trousers. With your tag example this tiddler would be listed too, but the trouser is blue. I think the direct assignment between type and color is necessary. Or is there another solution to search?
I concur with @pmario and @TW_Tones that fields would make so much more sense here. It will reduce the computational overload if your combination-search isn’t scanning for all tag combos, and it will allow you to set up efficient filters easily.
You can have filters looking for any combination of fields and values in those fields. For example, {{{ [trousers[blue]has[hat]!has[scarf]] }}} lists all tiddlers with blue in trousers field, and some value in hat field, but NO value in scarf field.
When it comes to your initial interest in a tag-combination frequency overview, I find myself wondering what patterns really matter, and why. A fields-based solution is likely to be more powerful.
It could be as simple as [all[]tag[white]tag[trousers]] however if the thing is trousers you could make one or more trousers tiddlers by having the field “thing” containing the value trousers, then all trousers is [all[]thing[trousers]] then only white ones ``[all[]thing[trousers]tag[white]]`
ChatGPT v3.5 says the following when asked;
Explain the difference between organising things with tags verses with field value pairs?
Organizing things with tags and organizing things with field-value pairs are two different ways to structure and categorize information.
Tags are keywords or labels that are assigned to items to help categorize them. They are typically user-defined and can be assigned to an item to indicate its relevance or to help find it later. Tags are flexible and allow for non-hierarchical organization, meaning that items can be tagged with multiple tags, and each tag can be applied to multiple items. This allows for a more organic, fluid way of categorizing items.
On the other hand, organizing things with field-value pairs involves defining specific fields for each item and assigning values to those fields. This approach is more structured and hierarchical, as each item must fit into a predetermined set of categories. For example, if you were organizing a collection of books, you might have fields for author, title, publication date, and genre. Each book would need to fit into one of these categories, and there would be no overlap.
In summary, organizing things with tags is a more flexible, user-defined way of categorizing items, whereas organizing things with field-value pairs is a more structured, hierarchical approach. The choice between the two will depend on the nature of the items being organized and the preferences of the person or organization doing the organizing.
Personally I would use tags for grouping things as needed, in an ad hoc way. I would use fields to categorise tiddlers, or give them (the tiddlers or products) attributes such as type, color subclass etc…
@TW_Tones I feel like this suggestion departs dramatically from @Ransche’s purpose. The project (described in post 18) focuses mainly on tiddlers for outfits (rather than individual garments). So, using a “thing” field with value “trousers” would not seem to make sense, especially because giving the whole tiddler a “white” tag (simply in virtue of having white trousers) would not allow OP to distinguish white-trousers blue-shirt from blue-trousers white-shirt outfits.
As @pmario suggested above, having a field for trousers (with any attributes of those trousers as values of the field) and a field for belt (with values as attributes of belt), etc., seems to be much clearer. Presumably tags would make sense only for “top-level” attributes of an outfit (business-casual vs loungewear vs athletic or that kind of conceptual space, perhaps, plus the actual tag “outfit” – if the wiki also has tiddlers for specific garment-types or styles, etc.)
Still, the details of a project like this will depend greatly on the purposes and workflow to which it’s devoted. Color names in particular are a huge data challenge! (To make searches meaningful, one needs a plan about whether to distinguish solid white from solid beige or ecru or khaki, all those from tan, tan from brown, and a way to handle any complexities like patterns, textures, stripes – which may or may not seem, at a distance, like the average of those colors…)
All this isn’t to discourage @Ransche but to highlight that getting meaningful data out (like how many outfits have white trousers with blue shirts) will depend on whether this universe of outfits offers neat cubby-holes for garment-types, colors, etc.
Perhaps it does, but I was simply illustrating a different and I argue better way to use fields and tags. I could have systematically reviewed the details of the project and hope to fully reverse engineer a full solution, but there is a limit to how much advice, especially when it is not the original request.
A full solution needs the designer to know the data they wish to represent and map that to an appropriate “data model”. This is something we can help with but to do it all is something more than that.
I was not sure if I should quote ChatGPT directly again, my prior quote was from ChatGPT 3.5 but I did use Chat GPT 4 this time and thought it may be a better answer. Of course I can work on it a little more before sharing
@Ransche welcome to the community, would you like a more thorough outline?