Yes, that’s right !
[a b c d e] means the one item defined as “a b c d e”.
The join[, ] is applied between adjoining items. But you only have one item. So there is nothing to join.
Remember: [a b c d e] is shorthand for title[a b c d e], meaning an item with the title “a b c d e”
Just for the giggles, toss aside for later if confusing…
Try [[a b c d e]split[ ]].
That says "take the item with the title “a b c d e”, and split the tile into pieces, splitting the title wherever there is a " " (space.) Now we have a list of individual items a, b, c, d, e.
Next, try Try [[a b c d e]split[ ]join[ ]]. That brings us a full circle back to one item: “a b c d e”
i guess what’s confusing is that up to now i’ve been under the impression that a filter must start with [ and end with ] but here it’s 3 different filters right? It’s as if there was an OR between them I guess. Except the last one forces the first two to pass through it.
One filter run is between [ and ]. Then the pieces inside of that make use of [ and ]. But you can’t next more square brackets in those.
[title[a b c d e]split[ ]join[ ]], that is one filter run. “title”, “split” and “join” are operators in that filter, and each operator has as a parameter wrapped in square brackets.
[title[a b c d e]split[ ]join[ ]] [title[f g h i j k]split[ ]join[ ]], that is a case of two filter runs, the resulting list of items from each run combined into one big list.
should be +[join[, ]] right?
that’s actually clear
ARG! Yes. I’ve got an eyeball on the hockey game while I’m typing, and I’m useless at multi-tasking…
I think I understand better now. Thank you. Now here’s a really difficult problem I can’t solve. It’s not directly related to my original question.
<$list filter="[kin:tags:to::{!!tag1}search:tags:some{!!search}]">
<$link to=<<currentTiddler>>/>
<br/>
</$list>
See the tags and some in that filter? I would like to turn those into variables. This doesn’t work for example (replacing some only for brevity):
<$set name="x" value=some>
<$list filter="[kin:tags:to::{!!tag1}search:tags:<x>{!!search}]">
<$link to=<<currentTiddler>>/>
<br/>
</$list>
Can’t figure this out 
Another burning question is this, here’s a filter:
[[blah]search[]]
output: blah
How do I make sure that search returns nothing in that case?
ARG ARG ARG ARG !!!
No, we do not need a “+”
[title[a b c d e]split[ ]join[ ]] . That’s a filter run. Everything between the outer [ and ] is one filter run. No + in there.
Now, say we have two filter runs: [title[a]] and [title[b]]
The actual filter looks like this: [title[a]] [title[b]]
that will result in a list of individual items:
If we want these items combined into one comma-separated item, then we want the following flter:
[title[a]] [title[b]] +[join[, ]
So the first filter run generates a list of one item (item “a”):
The second filter run generates a list of one item (item “b”):
And then the results of the first filter run and second filter run are combined, and we have:
Then the third filter run kicks in. The “+” says "hey, what we are about to do, we want done to all of the items we have so far (items a and b).
So the join applies to the whole bunch of items generated and aggregated during the previous filter runs.
After the third filter run (the join), we have a list with just one item:
awesome, thank you for that explanation. I guess for this to work filters must be evaluated from left to right, one at a time.
I can only think about using a macro there with text substitution. Nothing else seems to work
The problem with TiddlyWiki: too many filter operators.
I’m a minimalist. I toss aside what I consider unfortunate distractions.
Too large a vocabulary does a huge disservice to me. Some call it adding power, I call it unnecessary complexity in regards to learning, communications, documentation, and maintenance/debugging of TW instances.
I’ll only seek out and learn a new operator/feature when it hurts too much not to do that.
What I’ve found: 80% of what I want to do I can easily do with 20% of the plethora of features available.
The other 20% of the stuff I want to do, most of it I can easily do with the same 20% of the features.
It will involve more TW scripting steps, but I understand the steps, and I see clearly what is going on. They are the things I use all of the time, and never any once-in-a-blue-moon stuff I don’t remember how it works.
I tend to obsess about details and can’t fall asleep once i encounter something I don’t understand – not great i know.
@Charlie_Veniot has done a wonderful job of explaining how the outer square braces delinitate a filter run.
eg; [[abba]prefix[a]] the outer [ ] delimits the beginning and end of a filter run, inside the filter run we could call [ ] a default delimiter, in this case we define a title with title[abba] or just [abba]. Only one title inside a filter run then looks like this [[abba]] or this [title[abba]]
However if you introduce a variable or field value they already come with their own delimiters, so we no longer need to use the [ ] for example we use <varname> or {!!fieldname}
[<varname>match{!!fieldname}] would test if the varname matchs the contents of the fieldvalue (on the current tiddler).
< > or { } inside filters.{tiddlername} which defaults to the text field {tiddlername!!text}
<< >> {{ }} in part to set them apart from other braces in html such as <div> </div> which use the single < > already.Proceed below once you feel comphortable with the above
A nice little automatic feature in filters is fieldname[value] for example show-details[yes] will return a value/ be true if the fieldname show-details has the value yes.
show-details[yes] is effectively the same as [title[abba]]
Recent versions also allow macro’s in filters, which are just variables anyway <now YYYY0MM0DD>, put this inside a filter run and rather than use the whole $list widget, we can put the filter in a triple curly braces, or a “filtered transclusion” as follows, {{{ [<now YYYY0MM0DD>] }}}
Tripple braces / filtered transclusions
paramname={{{ filter }}} only the first result is assigned to the parameter.Hi @TW_Tones ,
Thank you so much for the thoughtful and quite comprehensive reply! Sorry it took me a long time to reply.
Could you give a more complete example of that?
I didn’t know that. Cool!
Hmm, would you mind showing both the legacy and new way in more complete contexts?
Would you also mind commenting on this: Filter questions - #13 by Surge and Filter questions - #14 by Surge. I have some nerve! Or to quote a character from Salterton Trilogy: the cheek, the cheek he has!
<$list filter=[{$:/config/design-mode}match[yes]]">
do this
</$list>
Perhaps a new thread with a more detailed explanation of what result you are after. When you ask for an intermediate result like “turn those into variables” it just makes it harder to understand your question and limits the possible answers we may give you.
Unfortunately, filter operator suffix values (e.g., :tags and :some) cannot be replaced with variables… unless the filter syntax is part of a macro definition. In that case, you can define the variables OUTSIDE the macro, and then use the $(varname)$ “macro substitution syntax” WITHIN the macro, like this:
\define showlist()
<$list filter="[kin:tags:to::{!!tag1}search:tags:$(x)${!!search}]">
<$link to=<<currentTiddler>>/>
<br/>
</$list>
\end
<$let x="some">
<<showlist>>
</$let>
Thank you Eric, that’s actually exactly what I ended up doing. Thank you!