Best "equal" operator?

[Mat]

I often want to test if e.g a field or variable has a certain value. How do I best do this in a filter?

[{foo!!bar}EQUALS[frotz]]

...what is "EQUALS" ?

<:-)

[Danielo Rodríguez]

[fieldname[value]] ? Isn't that what you are looking for

[Mat]

Doh! I knew that... how embarrassing. 

Still thanks - but the the question should only have been regarding variables.

[<var>EQUALS[frotz]]

<:-)

[Thomas Elmiger]

Hi Mat and Danielo

Some time ago I made a special macro for exactly this, maybe you want to use it or at least profit from my experiments:
https://tid.li/tw5/hacks.html#ifAisB%20%E2%80%93%20Compare%20if-then-else%20Style%20in%20Wikitext

Happy comparing!
Thomas

[Eric Shulman]

try this:

<$vars foo="bar">

<$list filter="[title<foo>] -[[bar]]" emptyMessage="foo EQUALS bar">

   foo does NOT EQUAL bar

</$list>

</$vars>

The [title<foo>] part of the filter dominantly appends the value of the variable.  Then the -[[bar]] part removes the literal value "bar".  If the result is an empty list, then foo is EQUAL to bar.  If the result is NOT empty, then we can say that foo does NOT EQUAL bar.

enjoy,

-e

Eric Shulman

TiddlyTools.com: "Small Tools for Big Ideas!" (tm)

InsideTiddlyWiki: The Missing Manuals

[Stephan Hradek]

What about the $reveal widget?

[Mat]

Thank you guys! As noted, the need is for it to be used inside a filter so Erics suggestion is the closest. It does have the limitation that you can't have other stuff in the filter because the filter will never be empty then. That's, of course, not what I asked for but I tried to simplify the question. Hopefully I can use this as a wrap around yet another filter.

Thank you!!

<:-)

[Stephan Hradek]

Am Montag, 28. August 2017 15:13:42 UTC+2 schrieb Mat:

Thank you guys! As noted, the need is for it to be used inside a filter

And you cannot put the "equal" outside the filter to use reveal?

[Mark S.]

If you can call the filter as a macro, or call a macro to make the filter, then this works:

\define compare(foo,bar)
<$list filter="[title[$foo$]regexp[^$bar$$]]" emptyMessage="no match">
Matches!
</$list>
\end

<<compare "stuff" "stuff">>

It needs to be set up as a macro so it can use regexp[^$bar$$] (or regexp[^$(bar)$$] if passed as an environmental variable.

What I don't understand, is why THIS doesn't work:

<$vars foo="stuff" bar="stuff">
<$list filter="[title<foo>field:title<bar>]" >
Matches!
</$list>
</$vars>

I've looked over the spec.s for the field operator. It should select an input title if an only it matches it's parameter. And the title operator should generate a tiddler title to be matched. But it doesn't seem to work that way. Instead, the field:title only returns the input title if the input title actually exists as a tiddler. But the spec's don't say that.

Good luck!
Mark

[Thomas Elmiger]

Eric’s solution works without title:

<$vars foo="froz" bar="froz">
<$list filter="[<foo>] -[<bar>]" emptyMessage="match">
no match
</$list>
</$vars>

@Stephan, do you suggest it would be better to use the reveal widget?

[Mark S.]

Here's a javascript filter  "equals" (based on 'field') to try. Since it compares based on text, not fields, operations like equals:myfield are meaningless. I left code in there that can process regular expressions, but didn't test if it still works since that approach to regular expressions has been deprecated.

After installing, these tests seemed to work as expected depending on what variables were set:

<$vars foo="stuff" bar="stuff">

<$list filter="[<foo>equals<bar>]">
THEY MATCH!
</$list>

<$list filter="[<foo>!equals<bar>]">
THEY DON'T MATCH!
</$list>
</$vars>

Have fun,

Mark

On Sunday, August 27, 2017 at 12:45:22 PM UTC-7, Mat wrote:

[Stephan Hradek]

Am Montag, 28. August 2017 23:44:51 UTC+2 schrieb Thomas Elmiger:

@Stephan, do you suggest it would be better to use the reveal widget?

No, I'm just wondering whether it might work.

I'm yet to completely understand the use case.

[Thomas Elmiger]

In my tests for the macro linked above I compared the reveal-way (it was suitable for my case). I decided to not use reveal because of the limitation of the reveal widget: You can’t use variables for both sides of the comparison. One – and users would have to know which one – would have to be a text reference like "!!fieldname". This also requires that users grasp the concept of text references. On the other hand if you use variables, it is easy to transclude a text reference’s value as value of the variable – {{!!fieldname}} does the job.

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/my9YIZEPGng/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+unsubscribe@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/c09b42b0-61d2-40d0-8921-fde3e314bfed%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Eric Shulman]

On Monday, August 28, 2017 at 11:41:05 PM UTC-7, Thomas Elmiger wrote:

In my tests for the macro linked above I compared the reveal-way (it was suitable for my case). I decided to not use reveal because of the limitation of the reveal widget: You can’t use variables for both sides of the comparison.

Actually, you CAN use variables for both "sides" of the reveal.... if you OMIT the "state" param, you can use the "default" param instead... like this:

<$reveal text=<<var1>> type="match" default=<<var2>> >
   <<var1>> equals <<var2>>
</$reveal>

enjoy,

-e

[Thomas Elmiger]

Arrrrrgh – why do I keep forgetting such elementary tricks?

Thank you, Eric!

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/my9YIZEPGng/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+unsubscribe@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/efd34bcc-07d7-4fc5-b11c-1633d4b691d4%40googlegroups.com.

[Mat]

A special use case of the above, for reference:

The following is to distinguish if a field has a specific value or any other arbitrary value (ie. that you don't know beforehand).

In this example, it is a field named "myfield" that has either the specific value foo or an arbitrary value.

<$list filter="[[mytiddler]myfield[foo]]"> value is foo </$list>

<$list filter="[[mytiddler]get[myfield]] -foo"> value is not foo </$list>

(You might want to add checks if the field exists at all etc)

In my real case, I use it as a way to distinguish between if something is a tag (specific value is tag) or a field (any arbitrary name).

I figure this was worth posting because of the non-symmetry that makes it less than obvious. If Mark S' PR is accepted then this would be simpler and symmetrical.

<:-)

[Stephan Hradek]

What's wrong with

<$reveal state="mytiddler!!myfield" type="match"   text="foo"              > value is foo     </$reveal>
<$reveal state="mytiddler!!myfield" type="nomatch" text="foo" default="foo"> value is not foo </$reveal>

[Mat]

Stephan, you're right. That is a much clearer! Thanks!

<:-)