improving smart resarch for in-situ macros for filter

[Jean-Pierre Rivière]

Today I wanted to see which tiddlers I have that are javascript.

In advanced research i can execute something like

[get[type]match[application/javascript]]

but it would only bring "application/javascript"

I can't have [filter[get[type]match[application/javascript]]]

because this is gross syntax error.

But if I had access to another input ext for a macro to be called extra I could do

extra : [get[type]match[application/javascript]]

research : filter<extra>sortan[]

and the job would be done.

BTW, I think a standard "nop" macro doing nothing would be useful. I'm using it many times when I have to decide for an eventual treatment, for (actual real) instance:

\define deleteProjectNewAltjson(target id)

<$action-log $$message="delete project «$target$##$id$»"/>

<$action-deletefield $tiddler="$target$" $field="$id$"/>

<$set name=next-step filter="[<target>getindex<id>]then[_kludge4deleteProjectNewAltjson]else[nop]]">

<<next-step "$target$" "$id$">>

</$set>

<$action-log $$message="deleted project «$target$##$id$»"/>

\end

(this concerns a potential bug for impossibility to delete a property of first level within a json object tiddler -- there is a separate thread I fielded yesterday for that)

I have not seen any other way to have a conditional call to a macro.

regards,

-- 

Jean-Pierre

[TW Tones]

Jean-Pierre,

On the first filter consider;

{{{  [all[]get[type]match[application/javascript]then<currentTiddler>] }}}

Untested, This should list the tiddlernames of the selected tiddlers (those with  [type]match[application/javascript])

Is that pArt of the problem.

I believe you can conditionally call macros, wrap them in a list or reveal widget.?

Tones

[Saq Imtiaz]

[all[tiddlers]] :filter[get[type]match[application/javascript]]

[Jeremy Ruston]

Hi Jean-Pierre

The idea of being able to specify variables for use in the advanced “filter” search has come up before, and is worth considering. My concern would be that using variables is relatively rare, and thus I wouldn’t like to make the default UI more complex.

It’s also worth noting that your example can be done directly without variables:

[field:type[application/javascript]]

Best wishes

Jeremy.

-- 
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/e0b372f9-39f2-4268-a31b-2d71cfa130een%40googlegroups.com.

[TW Tones]

Jean-Pierre / Jeremy,

The approach would possibly be a one off, new tab in advanced search, cloned from the filters tab ($:/core/ui/AdvancedSearch/Filter), edited to allow extra variables to be set, then used in the search.

Or a global macro to set the variables.

Easy  customisation for special use cases are everywhere in tiddlywiki. :)

Tones

[Jean-Pierre Rivière]

Saq, your example should be added to the "Filter Run Prefix (Examples)" tiddler of the doc.

Jeremy's is the best answer, but clearly both are convincing enough that the UI is about right today. And yes I was aware I could have a pablic macro help me, but that would not be very neat or a bit of hassle to setup and get rid of after use.

[Saq Imtiaz]

Filter run prefixes have seen a lot of improvements recently, and as such there is definitely room for more documentation.

The documentation is a community effort and maintained in the same git repo as the TW source code. Contributions to the documentation as PR are highly welcome.