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 On Tuesday, 4 May 2021 at 17:58:15 UTC+10 Jeremy Ruston wrote: > 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. > > > On 4 May 2021, at 08:50, TW Tones <[email protected]> wrote: > > 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 > > > > On Tuesday, 4 May 2021 at 17:42:30 UTC+10 [email protected] wrote: > >> 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 >> > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/e0b372f9-39f2-4268-a31b-2d71cfa130een%40googlegroups.com > > <https://groups.google.com/d/msgid/tiddlywiki/e0b372f9-39f2-4268-a31b-2d71cfa130een%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/b767e424-694a-4430-9ef8-37e9e3e3e1c5n%40googlegroups.com.
