How to insert partial filter expression into larger filter expressions?

I would like to re-use a small bit of a filter expression as a starting point for other, longer filter expressions. This filter string would sit in a field. Here’s what I’m looking at…

Base Filter Run = [!is[system]!is[shadow]tag[Contacts]]

I would like this to go inside a larger expression, such as…

[!is[system]!is[shadow]tag[Contacts]] :filter[has:field[City]!has:field[State]] +[!sort[title]]

This works just fine in a normal list:
<$list filter="[!is[system]!is[shadow]tag[Contacts]] :filter[has:field[City]!has:field[State]] +[!sort[title]]"/>

…but no matter how I try to slice it, I cannot figure out how to make the first Filter Run customizable. I always end up with the Base Filter Run being inserted as a single tiddler title. Field transclusions, macros, $Set/$Let variables…nope. :unamused:

It would be a lot easier if we were both looking at the same TiddlyWiki.

Taking a guess, do you mean something like this?

<$vars base_filter="[!is[system]!is[shadow]tag[Articles]]" >

<$list filter={{{ [<base_filter>] }}}>

<<currentTiddler>>

</$list>

</$vars>

Use the subfilter filter operator.

Assuming that the “customizable” filter is stored in a field named “BaseFilterRun” in the current tiddler, then you can write something like this:

<$let filt={{!!BaseFilterRun}}>
<$list filter="[subfilter<filt>] :filter[has:field[City]!has:field[State]] +[!sort[title]]"/>
</$let>

enjoy,
-e

Dammit. Speed demon …

Might as well throw out what I did, using TiddlyWiki.com:

<$let base_filter="[!is[system]!is[shadow]tag[Articles]]" 
            sub_filter=" :filter[regexp[free]]"
         full_filter={{{ [<base_filter>addsuffix<sub_filter>] }}}>

<$list filter={{{ [<full_filter>]  }}}>

<<currentTiddler>>

</$list>

</$let>

@EricShulman I’m getting an empty list with the following…

@Charlie_Veniot Very interesting. I’ll definitely play around with this…

Charlie got me something working :+1:, but Eric’s code is much more familiar-feeling to me, so I would like to get that working also. Two solutions are better than one.

Just to add to the mix if you are after a simple list with additional filtering the following works quite well ;

Filter from field
{{{ [subfilter{!!fieldname}] +[sort[]] }}}

Filter from Variable
{{{ [subfilter<filter-variable>] +[tag[todo]] }}}

Filter from tiddler;
{{{ [subfilter{tiddlername}] +[tag[todo]] }}}

Of note is filter fields and variables can contain a simple list of tiddlers.
eg {{{ [subfilter{!!list}] }}} however there is a list[] operator for the list field.

filter/subfilter operator is sometimes interchangeable, this reads nicely.

However subfilters can be of more value than that. They can contain filters of filters and used to remove items

\define inactive() [tag[done]] [tag[archive]]
{{{ [tag[todo]] -[subfilter<inactive>] +[count[]] }}}

is[] is a “selection modifier” filter operator. As such, it requires some input to modify. To make it work, you could add all[] at the beginning, like this: [all[]!is[system]!is[shadow]tag[Contacts]].

Alternatively, you could just start your base filter with the tag[Contacts] operator, which is also a selection modifier, but has an implicit all[] if used at the beginning of a filter run.

Thus, you could enter a base filter of [tag[Contacts]!is[system]!is[shadow]] to get the results you want. Note that this is also more efficient, since the TWCore uses an internal “index” to optimize the tag[] filter for improved performance.

You can also eliminate some unneeded default parameter values from the $edit-text widget, and combine the filter operators into a single run, like this:

<style>.stretchy { width:calc(100% - 2em);</style>
<$edit-text field="BaseFilterRun" class="stretchy"/>

<$list filter="[subfilter{!!BaseFilterRun}has:field[City]!has:field[State]!sort[title]]"/>

-e

Shadows are only listed if you use. [all[shadows+tiddlers]]

Default list for the all-operator is [all[tiddlers]] === [all[]].

I think the base filter shouldn’t use [!is[shadow]] since it only wastes time.

Inefficient filters are one reason, why the TW UI can become slow.

See: all operator docs

2 Likes