There is a small caveat.
One should take care of Empty value! The empty value is interpreted as 0!
--
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
Added to TW-Scripts
On Sunday, August 4, 2019 at 10:41:03 AM UTC+4:30, TonyM wrote:
>
> Mohammad,
>
> Comparing two values for which is the greater - 5.1.20 ONLY because it
> uses match and min operators
>
> <$set name=input1 value=3>
> <$set name=input2 value=5>
>
>
> <$list filter="=[!match]"
Really smart solution!
:-)
I am working to see how we can do branching using only $list widget and it
seems
It can be used in many cases!
The $list widget seems NOT a simple iterator and almost do many things just
its name is misleading for many users
--Mohammad
On Sunday, August 4, 2019 at
Mohammad,
Comparing two values for which is the greater - 5.1.20 ONLY because it uses
match and min operators
<$set name=input1 value=3>
<$set name=input2 value=5>
<$list filter="=[!match]" emptyMessage="equals">
<$list filter="=[minmatch]">
Input 1 = Minimum
<$list
Mohammad See your conditional operators link for my answer to your Question
One question, how do you propose to implement the below construct [Less
> than and greater than tests] using $list widget
Tony
On Sunday, August 4, 2019 at 12:15:09 AM UTC+10, Mohammad wrote:
>
> Tony!
>
>> See
Great stuff
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
Tony!
> See this post!
>
https://groups.google.com/d/msg/tiddlywiki/xiCrpbATFqE/w-UjRxroFQAJ
--
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
Tony
Have a look here, then else operator
https://github.com/Jermolene/TiddlyWiki5/issues/4147
On Saturday, August 3, 2019 at 4:00:07 PM UTC+4:30, TonyM wrote:
>
> Mohammad,
>
> Your first resort would be to the reveal widget since it already permits
> such comparisons. I had raised the
Yes, the reveal widget is one solution!
It is important to have a readable and maintainable code!
--Mohammad
On Saturday, August 3, 2019 at 4:00:07 PM UTC+4:30, TonyM wrote:
>
> Mohammad,
>
> Your first resort would be to the reveal widget since it already permits
> such comparisons. I had
Mohammad,
Your first resort would be to the reveal widget since it already permits such
comparisons. I had raised the development of less than and greater than
operators but there is a real issues these raise because such tests need to
take account of the complexity inherent in numbers. I am
Tony,
One question, how do you propose to implement the below construct using
$list widget
if a>b then
do this part one
else if a
> Your welcome
>
> So on 5.1.20
> <$list filter="[] ~[[false]]" variable=case>
><$list filter="[match[false]]" variable=case>
> Do this if no case
Added to TW-Scripts!
On Thursday, August 1, 2019 at 3:46:23 AM UTC+4:30, TonyM wrote:
>
> Your welcome
>
> So on 5.1.20
> <$list filter="[] ~[[false]]" variable=case>
><$list filter="[match[false]]" variable=case>
> Do this if no case value
>
><$list filter="[match[caseone]]"
Ciao TonyM
I sat a bit with this and your last post that lists useful requests I've
noted.
I think the issue, at root, is "regex" is an powerful pattern matching
"language" built into JavaScript that TW has access to.
And its wortrh noting that a lot of TiddlyWiki, behind the scenes, uses it
And
With *2019-08-01* give *20190801* (remove delimiters
or return
2019
08
01
Do the reverse? add "-" tt position 4 6 8
Regards
Tony
On Friday, 2 August 2019 08:04:18 UTC+10, TonyM wrote:
>
> Josiah,
>
> I am busy at the moment but I am sure I can brainstorm some cases for
> regex.
>
>
Josiah,
I am busy at the moment but I am sure I can brainstorm some cases for
regex.
Does defining a macro containing the regex then using regexp resolve
the use of "[ ]"?
Off the top of my head
- The equal test (already)
- The Not equal test if there is one
- Searching for common
Yes that is true!
Using SnR when I want to rename tiddlers like tid01/example01 to
tid01\example01 or change a filter [tag[mytag]] to [tag]
I encounter problem.
By the way, finding a string ended by say *myword *or contains a special
format like *date *or *number *are among cases we cannot use
An issue in TW in filters with regex is that "[" "]" are needed too in
regex for "character classes" (e.g. [a-f, A-G]) to get them to work
requires a bit more than normal regex since you can't use square brackets
directly in TW regex filters, otherwise its works as expected.
A few things like
I like regular expressions a lot.
I'm not clear what people need though.
The kind of thing I do with them I doubt most poeople would be interested
in.
I'll think about it.
Maybe what is needed is an overview of the use of regex in TW (which is
much wider actually than operators)? I think
Josiah,
I would also appreciate if you could provide examples of common and regexp
in TW!
You favored me and provided a help page for SnR in Tiddler Commander!
I know regexp is very powerful but in tiddlywiki.com there is little
documentation on that!
You can have a daily post like *An Example
TonyM wrote:
>
>
> I would not underestimate the value of a plain English operator like match
> for easy to read tests especially when they control visibility and
> structure in code.
>
Don't disagree. But its not a straw man. Its the intelligent man--when you
need her. Your example triumphed
Josiah
I would not underestimate the value of a plain English operator like match for
easy to read tests especially when they control visibility and structure in
code.
On regex you could give the community A great resource if you provide 10 to 20
top regex tests we may want to use. I could
>
> Now we would say
> [regexp[^caseone$]]
The difference here is that ^ is the marker for "start of string" and $
"end of string", regex meta characters.
But there would be no difference between [regexp[caseone]] and
[match[caseone]]
So you are not really comparing equal cases. It
An aside in this thread.., but not irrelevant.
Mat: I barely even know regexp badly. That is basically the only one I
> know for exctly the reason of being able to make an exact comparison. BUT
> don't take my word for it, I just found it on the web..
Regex is one of few areas of computing
Your welcome
So on 5.1.20
<$list filter="[] ~[[false]]" variable=case>
<$list filter="[match[false]]" variable=case>
Do this if no case value
<$list filter="[match[caseone]]" variable=case>
Process "caseone"
<$list filter="[match[casetwo]]" variable=case>
Thanks Tony!
This is great for code readability!
Cheers
Mohammad
On Wednesday, July 31, 2019 at 5:46:25 PM UTC+4:30, TonyM wrote:
>
> Folks,
>
> Ad a result of Jeremy adding a new match operator to 5.1.20 the case
> statements in this code pattern will be even more user friendly.
>
> First we
Folks,
Ad a result of Jeremy adding a new match operator to 5.1.20 the case statements
in this code pattern will be even more user friendly.
First we would say
[prefix[caseone]suffix[caseone]]
Now we would say
[regexp[^caseone$]]
But this Will become which is easier to remember
Mat - thanks for your Idea never the less
By the way prefix[one]suffix[one]]
Is the closes to exact match we have. I expect onesomethingone will bypass
this.
regexp[^one$]
is thus very helpful
So the case can MAY now look like this but I expect the :: needs to be
removed and "false" not a
On Sunday, July 28, 2019 at 2:11:39 AM UTC+2, TonyM wrote:
>
> Mat,
>
> I expect it would suffice. I assume that is an equivalent for equal or
> prefix[one]suffixe[one]]?
>
AFAIK it is used for exact match so it is not equivalent to prefix-suffix.
> If you know regex well I could generate a
Mat,
I expect it would suffice. I assume that is an equivalent for equal or
prefix[one]suffixe[one]]?
There is a bit of a barrier to all users using regexp. What would be nice
is if some of the common ones like you demonstrated were documented for
general users to use. Especially for the
Interesting pattern. should be useful.
If we ever get an equals[] operator this would become
> [<__x__>equals[one]]
> Not real yet :)
>
Would regexp[^one$] suffice?
<:-)
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this
On Saturday, July 27, 2019 at 2:20:34 PM UTC+4:30, TonyM wrote:
>
> Mohammad,
>
> Yes the single prefix statement allows oneWord where "one" is the prefix
> of another "word"!
>
> And to do what you say more literally you could use "contains[one]"
>
> This of course can be stopped if required
Mohammad,
Yes the single prefix statement allows oneWord where "one" is the prefix of
another "word"!
And to do what you say more literally you could use "contains[one]"
This of course can be stopped if required with
filter="[<__x__>prefix[one]suffix[one]]"
If we ever get an equals[]
Thanks Tony!
It works great! I also used a simple version as this
\define case(x)
<$list filter="[<__x__>prefix[one]]">
This is case one.
<$list filter="[<__x__>prefix[two]]">
This is case two
<$list filter="[<__x__>prefix[three]] [<__x__>prefix[four]]">
This is case three and four
\end
<>
Mohammad,
I some ways I built this so the empty message did not require a macro, to
keep all the logic in the one block.
I would imaging people would copy such a block as follows
<$list filter="[] ~[[::false]]" variable=case>
<$list filter="[prefix[::false]]" variable=case>
Do this
Hi Tony!
This is great and needs some examples to explore the pros and cons!
By the way as you said the application may vary case by case and a macro
may not be a good option.
--Mohammad
On Saturday, July 27, 2019 at 4:18:31 AM UTC+4:30, TonyM wrote:
>
> Mohammad,
>
>
>> We need to wrap
yes!! more!! I'll be srudying this...
--
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+unsubscr...@googlegroups.com.
To view this discussion on the
Mohammad,
> We need to wrap inside a macro to present a construct like
>
> <>
>
>>
>>
>
In someways I am suggesting you do not need to make a "select-case macro "
because the whole case structure including the empty case can be written
inside the one outer list object. Thus it may be
Mohamad,
I have rewritten the code pattern to suit your "else" use case
> I use a lot $list as
>
> if *filter**-not-**empty* do-this *else* do-that
>
>
>- filter is not empty do what is given inside $list widget
>- filter is empty go for emptyMessage
>
>
<$list filter="[]
Hi Tony
This is interesting!
Could you give some simple examples?
We need to wrap inside a macro to present a construct like
<>
What do you think?
I use a lot $list as
if *filter**-not-**empty* do-this *else* do-that
- filter is not empty do what is given inside $list widget
-
Post Script the above is not tested.
On Friday, July 26, 2019 at 2:20:31 PM UTC+10, TonyM wrote:
>
> I just wanted to share this code pattern I just discovered for Handling
> the emptyMessage condition in the ListWidget Body.
>
> Sometimes the way we write Filters the only way to proceed is to
40 matches
Mail list logo
