Recursive filter operators to show all tiddlers beneath a tag and all tags above a tiddler

You can find the taggingtree and tagstree filter operators as plugins at https://yaisog.tiddlyhost.com

Have a nice day
Yaisog

6 Likes

Added to the CPL, thanks

https://tw-cpl.netlify.app/#Plugin_202302034048668%201%201:[[Plugin_202302034048668%201%201]]%20[[Plugin_202302034048668%201%201%201]]%20Plugin_202302033851321%20Plugin_202302034048668%20[[Plugin_202302034048668%201]]%20Index

1 Like

I agree we should have a more general filter operator in the core to get tree.

I’m creating a flow chart plugin that can show the tree, and I will allow user to use custom field, not limited to tags field. So I have to copy&paste and do modification to your code, instead of reuse it and just pass-in parameters.

1 Like

Thanks for sharing and its a very useful set of tools.

I do want to point out however; you say in the readme for tagging tree filter

Infinite (or recursive) filters cannot be defined in TiddlyWiki

  • This may be technically true but it is important to note this is only if one restricts oneself to a single filter.

It is true to say;

Infinite (or recursive) code can be defined in TiddlyWiki

  • It is quite easy easy in TiddlyWiki to implement recursive processes using a macro that calls itself.
    • one one hand you may need to add a little code to detect loops if the data is not hierarchical.
    • But on the other hand recursive macros present more possibilities to use and display intermediate values. Including but not limited to
      • counts, totals and calculations for each subtree
      • Separating the nodes (leaves) from branches (folders) and treating each differently
      • Visually representing the hierarchy
  • I have not yet investigated but the MAP filter/filter run, may be also helpful with fixed depth recursion.

It is important to recognise that obtaining a list of tiddlers in a hierarchy from a filter only returns the list of tiddlers in that hierarchy and that intermediate and accumulation of values associated with those tiddlers may very well need to iterate this list of titles one or more times, to extract information that someone is after.

  • Macro based recursive functions can collect this information in a single iteration of the hierarchy.

This is an important distinction to make when designing solutions because along with using two filters and nesting list widgets, it is not always as efficient to cram all functionality into a single filter, when when have other structures that can often provide more efficient solutions depending on the use case.

Not withstanding the above it is true there is a whole class of problems where your traggingtree and tagstree filters are very easy to use and efficient.

  • These filters is perfect for Identifying a list of tiddlers on which to apply a common action or calculation which can only be found “walking a tree”.

What to look for?

  • There is a class of coding cases where if you find yourself using one of your new operators multiple times, or the list of titles so generated by those filters multiple times it may be better to look at this alternative approaches.
  • Designers may consider the kin filter for more complex and non-tag tree filtering or using nested lists and self calling macros for other cases.

I use this plugin a lot in my personal task management plugin. And I found a bug, when two tiddler use taggingtree[], the output will be inconsistent. Do you have a Github repo for this to rise issue?

reproduce link

\define filter-is-not-leaf() [all[current]tagging[]filter<filter-is-new-task>] 

\define filter-non-completed-leaf-tasks() [all[current]debug-log[]taggingtree[]debug-log[]!filter<filter-is-not-leaf>filter<filter-is-new-task>]

try switching to left most tab here to reproduce, see console for log

Hi,
I’ve debugged into this and found that the assignment

var intermediate = options.wiki.getTiddlersWithTag(title)

for the title 摸鱼时展示待办的userscript in one case returns two tiddlers:
写userscript的太微配置页面 and 写userscript的配置页面.
In the other case, the assigment return an empty set. So either you’re doing something with the tags so that these two tiddlers are not found in the list of tagged tiddlers, or it’s a problem with the getTiddlersWithTag() function. The filter code seems to work OK with the data it is getting.

You could try substituting the taggingtree[] filter with subfilter<temp>, with

\define temp() [tagging[]] [tagging[]tagging[]] [tagging[]tagging[]tagging[]] [tagging[]tagging[]tagging[]tagging[]]

and see if you get different results (I think in this particular case you only need 4 levels of tagging[] depth.)

Have a nice day
Yaisog

Thanks, Yaisog, I will continue debug this in the core’s js. Or probably it will be my problem.

Anyway, this plugin is very suitable for collecting trees of tasks (with dependency when doing them) into a dynamic table, nice work!

I’m referencing your code to create a in-tagtree-of[xxx] filter operator to solve How to test filesystempath easily

Here comes the GitHub - tiddly-gittly/in-tagtree-of: Fast version of `kin::to[xxx]`

https://tiddly-gittly.github.io/in-tagtree-of/

Code mostly copied from yours, and add the cache from kin-filter.

Seems @bimlas also tried to merge kin-filter into the core 5 years ago…

https://groups.google.com/g/tiddlywiki/c/YZlPGP0qX1o

Yeah, I think @TW_Tones mentioned this once.

Hi,

i am sorry ,but what is the alternative to to a text widget when doing sums,

because i used to do this

[kin::to<currentTiddler>get[field]sum[]]

then show it in a text widget

now

[<currentTiddler>taggingtree[]get[field]sum[]]">

doesnt work with a text widget and only sums one level down

Hi @paulgilbert2000, difficult to say what the problem is without a live example. Filters generally don’t depend on the widget they’re used in.
You could try debugging the filter with the debug-log operator from here:
https://yaisog.tiddlyhost.com/#%24%3A%2Fplugins%2Fyaisog%2Fdebug-log-filter

You might first want to check if the list of tiddlers after kin[] and after taggingtree[] are the same.

My bad , i got myself all confused , the only difference is that kin filter in sum operations counts the current tiddler ,where as tag tree doesn’t .

Thank you very much for the filter, its way way faster than kin filter!!

@linonetwo would it be possible for you to publish and English version of your revised plugin?. I am keen to make extensive use of it. Sorry I can read Chinese :frowning:

I’m currently making heavy usage of kin:list:to[] and kin:list:from[] to return the whole list of related tiddlers using the list fields. If I’m reading this correctly, I’m not able to take advantage of these improved performance versions as I’m using list fields intead of tags - is that correct?

@TW_Tones Recently @dongrentianyu add the translated content with the help of deepl, you can switch to it using this drop down!

The PR is in docs: 借助deepl翻译文档 by dongrentianyu · Pull Request #4 · tiddly-gittly/in-tagtree-of · GitHub , If you find any misspell or place that is not fluent, don’t hesitate to make a PR to improve it. We are translating doc site in this way until we have a better solution to How to translate 3rd party plugin demo website?

1 Like

Yes, I use $tw.wiki.getTiddlersWithTag so only support tags. But you can try add new logic, or just fork to create a new operator. I fork most of the code from @Yaisog 's version too.

I think in your examples, “child” should be “descendant”.

It probably doesn’t matter to you per se, but to anyone in Europe or North America who wants to contribute, the use of Simpsons images is probably not fair use and may violate trademarks. Large companies will sometimes pursue even small infractions of their copyrights. It’s just tidier if you can avoid those complications.

What’s the difference?

I just copy them from elsewhere, maybe kin-filter’s doc? I don’t really like this kind of cartoon, I hope someone or I can have time to turn them into waifu using stable difussion.