@TW_Tones, I know you marked this discussion as solved, but I just came across it and decided to add my 2 cents.
From your original problem statement it sounds like you wanted to write a filter whose output will be a list of filters and your chosen approach is to embed a separator character and then use the split filter operator to convert the string into a list of filters.
The cascade filter operator is another place where it is required to provide a filter which generates a list of filters. For typical uses of that operator, the filters are stored in separate tiddler fields and a filter which selects the contents of those tiddler fields serves the purpose of being the “filter generating filter”.
Last year when I wrote the cascade filter extended example, I wanted to be able to use a single string to generate multiple filters. I thought of using a delimiter with split like you are doing, but I worried it would complicate the explanation. I settled on storing the filters in separate tiddler fields.
But just last week I discovered the syntax for filters allows for a list of filters to be concretely specified in a single string. The trick is that when filter runs are delimited by single or double quotes, then what is inside those quotes will not be further parsed for filter syntax. That means you can include square braces and other punctuation required for specifying filters.
To be concrete, pretend you want to generate this list of 3 (not particularly useful) filters:
-
[all[]] :map[split[]first[1]] - returns the first character of each input title
-
[all[]] :map[split[]last[1]] - returns the last character of each input title
-
[length[]] - returns the character length of each input title.
Using quote characters you can write a filter which will return the above three filters like this:
"[all[]] :map[split[]first[1]]" "[all[]] :map[split[]last[1]]" "[length[]]"
Paste the above into the filter tab of the advanced search and you will get the 3 filters as output. All without using any “home-grown” delimiter. The quotes are the delimiters and tiddlywiki filter parsing natively supports them.
In later posts you reveal that you also want to associate each filter with the name of a field to operate on. IMO to “go with the grain” of tiddlywiki, it is best to keep those names as a separate list and use the setmultiplevariables widget to tie the names together with the filters.
For example, the code for your “reference” button could look like this:
<!-- For convenience of this example, set variables using the let
widget. Maybe in your real use-case the variables would be input
parameters to a macro -->
<$let
referenceFiltersFilter='
"[[done]] [[archive]] -[[todo]]"
"[<now YYYY0MM0DD0SS0hh0mm0ss0XXX>]"
'
referenceFieldsFilter='tags reference-date'
>
<$setmultiplevariables
$names=<<referenceFieldsFilter>>
$values=<<referenceFiltersFilter>>
>
<$list filter=<<referenceFieldsFilter>>>
Insert your own action list-ops widget here which will set the
field ''<$text text=<<currentTiddler>>/>'' using the filter
''<$text text={{{[<currentTiddler>getvariable[]]}}}/>''
</$list>
</$setmultiplevariables>
</$let>
Output of the above looks like this:
Insert your own action list-ops widget here which will set the field tags using the filter [[done]] [[archive]] -[[todo]]
Insert your own action list-ops widget here which will set the field reference-date using the filter [<now YYYY0MM0DD0SS0hh0mm0ss0XXX>]
There are pros and cons to this approach and it might not fit your use case. I just wanted to share my new-found way of using quote delimiters to write filter-generating filters.
