5.2.0 New Features: Macro Parameters in Filter

[Mohammad]

Tiddlywiki 5.2.0 supports macro parameters inside Filter

Ref:

Example

The below script shows the use of qualify macro with one input parameter

\define myMacro(stateTid:"")
<$vars stateTid={{{ [<__stateTid__>!is[blank]then<qualify "$:/temp/slider/$(currentTiddler)$/$stateTid$">else<qualify "$:/temp/slider/$(currentTiddler)$">]}}} >

This is <$text text=<<stateTid>> />

</$vars>
\end

The below examples produces:

<<myMacro>>

<<myMacro sample>>

This is $:/temp/slider/Draft of 'New Tiddler 4'--2130246815

This is $:/temp/slider/Draft of 'New Tiddler 4'/sample--2130246815

Important Note This is a wiki post! So any user here can edit it!
I highly recommend all users share their examples/use cases here and improve the docs!

[saqimtiaz]

The last solution proposed in this answer is another example of using macro parameters inside a filter:

Filter to list tiddlers matching user-input field values

@Pak I don’t have the opportunity at present to think about your data structure carefully and a specific solution but here are some thoughts that might help. The filter operator and :filter and :map filter run prefixes should be useful here. Here is some untested code to give you an idea as to the direction I am thinking, can probably be improved upon: \define subject-filter() [{$:/temp/test##subject}!is[blank]match{!!subject}] :else[{$:/temp/test##subject}is[blank]then[keep-me]] \define med…

[TW_Tones]

I also gained a new respect for this feature over here Simpler Accordion Macro - #16 by TW_Tones because although it only simplifies thing a little it can have a substantial advantage feeding content from various sources into a macro without needing to build the “infrastructure” in the macro to handle the sources.

I am now a big fan of this change.

[saqimtiaz]

One can actually get pretty creative with literal macro parameters in filters.

For the following, assume the existence of a simple global macro as follows:

\define .printf(text) $text$

You can use this to avoid the need for a separate variable for a filter operand as long as it does not contain the character >

For example:

{{{ [tag[HelloThere]filter<.printf "[{!!text}length[]compare:integer:gteq[1000]]">] }}}

instead of:

\define larger-than-1k() [get[text]length[]compare:integer:gteq[1000]]

{{{ [tag[HelloThere]filter<larger-than-1k>] }}}

---

It gets better, since we are feeding our text into a macro, it means that anything in the $(varname)$ syntax will get replaced by the relevant variable values. Example:

{{{ [<.printf "This is the tiddler $(currentTiddler)$">] }}}

Unfortunately, what wont work is trying to substitute variables that are set by filter run prefixes or operators. So for example, while the :map filter run prefix (in the pre-release) sets the index and length variables the following will not work:

{{{ [tag[HelloThere]] :map[<.printf "$(index)$ of $(length)$ - $(currentTiddler)$">] }}}

Instead we have to do it the old fashioned way:
{{{ [tag[HelloThere]] :map[<currentTiddler>addprefix<length>addprefix[ of ]addprefix<index>] }}}

There might be a way to support these variables in macro params within filters as well, but it would necessitate a low level change to the base Widget class and would therefore need to be considered very carefully.

---

Personally I have been using a custom printf[] operator which handles this use case well. Syntax:

{{{ [tag[HelloThere]] :map[[$(index)$ of $(length)$ - $(currentTiddler)$]printf[]] }}}

---

Background: a while back I hacked the filter syntax to allow the characters `` as a delimiter for literal filter operands, which allows characters like []{}<> within them and automatically substitutes variables. It occurred to me that most of that can now be done with literal macro params.