I feel difficult to express "or" in filter expression

The OR relation ship is difficult to use.

For example, I want to search tid or md,

[!is[shadow]!is[system]field:type[text/vnd.tiddlywiki]search[xxx]]

It will be difficult to use OR without repeating [!is[shadow]!is[system]field:type

[!is[shadow]!is[system]field:type[text/vnd.tiddlywiki]] [!is[shadow]!is[system]field:type[text/markdown]] +[search[xxx]]

In Regexp, we can use ( xxx | yyy ) to create a group with OR relationship, but it is not trivial in filter expression.

As I read it you dont just want OR,

You want this OR that THEN search?

Perhaps we forget the “OR Question” and ask us for the result you want.

Is this correct?

If the type field is text/vnd.tiddlywiki search all these tiddlers for xxx
If the type field is text/markdown search all these tiddlers for xxx

If that is what you want, I have a few approaches, but why not use two lists?

  • I also like using functions to modularise filters.

Yeah, may not be as simple as programming langues, but no reason not to just use multiple lists

<$list filter="[!is[shadow]!is[system]]">
<$list filter="[field:type[text/vnd.tiddlywiki]] [field:type[text/markdown]] +[search[xxx]]">

</$list>
</$list>

Try something along these lines:

[!is[shadow]!is[system]] :filter[[text/vnd.tiddlywiki,text/markdown]split[,]match{!!type}] :and[search[xxx]]

Alternatively (might be faster):

[type[text/markdown]] [type[text/vnd.tiddlywiki]] :and[!is[shadow]!is[system]search[xxx]]
1 Like

No, I just want to search md or tid, in a bot

but “if this else then do that” is also a common problem. This is because filter expression is one-dimensional, there can’t be branchs.

When we can use widgets, this won’t be a big problem, we can even use Let or Var widget to store intermediate results, to create logic-branch.

I mostly encounter this problem when I integrate with other systems, like bot, calendar library.

This seem to be a good way to make those operators accept multiple input, while they can only accept one input.

Because there is a field-indexer?

Yes, field looksups are indexed.