[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mohammad]

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 tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/7fcbe32b-78f3-48ab-8eb1-8e369869cedc%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mohammad]

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]" emptyMessage="equals">
><$list filter="=[minmatch]">
>   Input 1 = Minimum
>
><$list filter="=[maxmatch]">
>  Input 1 = Maximum
>
> 
>
> 
>
>
> Tony
>
> On Saturday, August 3, 2019 at 8:52:03 PM UTC+10, Mohammad wrote:
>>
>> 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>  do this part two
>> end
>>
>>
>>
>>
>> or only 
>>
>> if a< b then
>>  do this true part
>> end
>>
>>
>>
>> Now using match we can implement if a=b.
>>
>> --Mohammad
>>
>>
>> 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]]" variable=case>
>>> Process "caseone"
>>>
>>><$list filter="[match[casetwo]]" variable=case>
>>> Process "casetwo"
>>>
>>><$list filter="[match[casethree]]" variable=case>
>>> Process "casethree"
>>>
>>>
>>> 
>>><$list filter="[match[casetwo]] [match[casethree]]" 
>>> variable=case>
>>> Process "casetwo" and "casethree"
>>>
>>> 
>>>
>>> Regards
>>> Tony
>>>
>>> On Thursday, August 1, 2019 at 3:34:59 AM UTC+10, Mohammad wrote:

 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 would say
>
> [prefix[caseone]suffix[caseone]]
>
> Now we would say
> [regexp[^caseone$]]
>
> But this Will become which is easier to remember
> [match[caseone]]
>
> The regex example still points us to the best approach for more 
> complex tests but match will work for many common cases. 
>
> I will now abandon only testing the negative in binary comparisons 
> such as
> [] -[[false]]
>
> becomes
> [match[true]]
>
> the case insensitive option may also help when var or 
> [{$:/temp/tiddler}] was provided by the user in case they entered tRue 
> and 
> other combinations by mistake.
>
> Thanks Jeremy
> Tony
>
>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/28c336f5-20f9-433f-8b4b-055c5c73c8ac%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mohammad]

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 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]" emptyMessage="equals">
><$list filter="=[minmatch]">
>   Input 1 = Minimum
>
><$list filter="=[maxmatch]">
>  Input 1 = Maximum
>
> 
>
> 
>
>
> Tony
>
> On Saturday, August 3, 2019 at 8:52:03 PM UTC+10, Mohammad wrote:
>>
>> 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>  do this part two
>> end
>>
>>
>>
>>
>> or only 
>>
>> if a< b then
>>  do this true part
>> end
>>
>>
>>
>> Now using match we can implement if a=b.
>>
>> --Mohammad
>>
>>
>> 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]]" variable=case>
>>> Process "caseone"
>>>
>>><$list filter="[match[casetwo]]" variable=case>
>>> Process "casetwo"
>>>
>>><$list filter="[match[casethree]]" variable=case>
>>> Process "casethree"
>>>
>>>
>>> 
>>><$list filter="[match[casetwo]] [match[casethree]]" 
>>> variable=case>
>>> Process "casetwo" and "casethree"
>>>
>>> 
>>>
>>> Regards
>>> Tony
>>>
>>> On Thursday, August 1, 2019 at 3:34:59 AM UTC+10, Mohammad wrote:

 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 would say
>
> [prefix[caseone]suffix[caseone]]
>
> Now we would say
> [regexp[^caseone$]]
>
> But this Will become which is easier to remember
> [match[caseone]]
>
> The regex example still points us to the best approach for more 
> complex tests but match will work for many common cases. 
>
> I will now abandon only testing the negative in binary comparisons 
> such as
> [] -[[false]]
>
> becomes
> [match[true]]
>
> the case insensitive option may also help when var or 
> [{$:/temp/tiddler}] was provided by the user in case they entered tRue 
> and 
> other combinations by mistake.
>
> Thanks Jeremy
> Tony
>
>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/c288f13d-5c2e-4b2e-a34e-8190cbd68129%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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 filter="=[maxmatch]">
 Input 1 = Maximum
   





Tony

On Saturday, August 3, 2019 at 8:52:03 PM UTC+10, Mohammad wrote:
>
> 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  do this part two
> end
>
>
>
>
> or only 
>
> if a< b then
>  do this true part
> end
>
>
>
> Now using match we can implement if a=b.
>
> --Mohammad
>
>
> 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]]" variable=case>
>> Process "caseone"
>>
>><$list filter="[match[casetwo]]" variable=case>
>> Process "casetwo"
>>
>><$list filter="[match[casethree]]" variable=case>
>> Process "casethree"
>>
>>
>> 
>><$list filter="[match[casetwo]] [match[casethree]]" 
>> variable=case>
>> Process "casetwo" and "casethree"
>>
>> 
>>
>> Regards
>> Tony
>>
>> On Thursday, August 1, 2019 at 3:34:59 AM UTC+10, Mohammad wrote:
>>>
>>> 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 would say

 [prefix[caseone]suffix[caseone]]

 Now we would say
 [regexp[^caseone$]]

 But this Will become which is easier to remember
 [match[caseone]]

 The regex example still points us to the best approach for more complex 
 tests but match will work for many common cases. 

 I will now abandon only testing the negative in binary comparisons such 
 as
 [] -[[false]]

 becomes
 [match[true]]

 the case insensitive option may also help when var or 
 [{$:/temp/tiddler}] was provided by the user in case they entered tRue and 
 other combinations by mistake.

 Thanks Jeremy
 Tony



-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/05812caa-0364-4d91-9734-bd0a8a486de5%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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 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 tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/2098abc2-1c28-426c-ac6e-1083c06388f7%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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 
https://groups.google.com/d/msgid/tiddlywiki/4cd8321e-457b-4293-a2bb-3df193be8443%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mohammad]

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 tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/68b17c34-95e8-40d8-ad92-1ff9c33412f8%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mohammad]

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 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 sure 
> JavaScript can help.
>
> Never the less I will give your questions some thought and see if I can 
> craft a method with existing features. Then if we can't get something that 
> resembles plain English or is not too complex we can ask the developers.
>
> One method may be using one of the sort operators then testing the first 
> in the list. One trick could be to test if the original list ie two items 
> is in the same order after sorting or not. If such tests can be written in 
> a subfilter they could be easy to read 
> Eg [] [] +[subfilter[firstgreater]]
> Is true or not.
>
> Thanks for the challenge, I hope others take it on as well.
>
> Though do remember the rereleased version of Evans formulas plugin can do 
> all of this.
>
> Regards
> Tonu
>
>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/b0b13e83-62b1-4a14-8b13-fd72bbb3aead%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mohammad]

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 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 sure 
> JavaScript can help.
>
> Never the less I will give your questions some thought and see if I can 
> craft a method with existing features. Then if we can't get something that 
> resembles plain English or is not too complex we can ask the developers.
>
> One method may be using one of the sort operators then testing the first 
> in the list. One trick could be to test if the original list ie two items 
> is in the same order after sorting or not. If such tests can be written in 
> a subfilter they could be easy to read 
> Eg [] [] +[subfilter[firstgreater]]
> Is true or not.
>
> Thanks for the challenge, I hope others take it on as well.
>
> Though do remember the rereleased version of Evans formulas plugin can do 
> all of this.
>
> Regards
> Tonu
>
>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/b1696ee1-e631-4ee3-a22e-1afaf3d94d96%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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 sure JavaScript can 
help.

Never the less I will give your questions some thought and see if I can craft a 
method with existing features. Then if we can't get something that resembles 
plain English or is not too complex we can ask the developers.

One method may be using one of the sort operators then testing the first in the 
list. One trick could be to test if the original list ie two items is in the 
same order after sorting or not. If such tests can be written in a subfilter 
they could be easy to read 
Eg [] [] +[subfilter[firstgreater]]
Is true or not.

Thanks for the challenge, I hope others take it on as well.

Though do remember the rereleased version of Evans formulas plugin can do all 
of this.

Regards
Tonu

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/10daccad-f495-41cc-bc88-ca6937161c00%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mohammad]

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 value
>
><$list filter="[match[caseone]]" variable=case>
> Process "caseone"
>
><$list filter="[match[casetwo]]" variable=case>
> Process "casetwo"
>
><$list filter="[match[casethree]]" variable=case>
> Process "casethree"
>
>
> 
><$list filter="[match[casetwo]] [match[casethree]]" 
> variable=case>
> Process "casetwo" and "casethree"
>
> 
>
> Regards
> Tony
>
> On Thursday, August 1, 2019 at 3:34:59 AM UTC+10, Mohammad wrote:
>>
>> 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 would say
>>>
>>> [prefix[caseone]suffix[caseone]]
>>>
>>> Now we would say
>>> [regexp[^caseone$]]
>>>
>>> But this Will become which is easier to remember
>>> [match[caseone]]
>>>
>>> The regex example still points us to the best approach for more complex 
>>> tests but match will work for many common cases. 
>>>
>>> I will now abandon only testing the negative in binary comparisons such 
>>> as
>>> [] -[[false]]
>>>
>>> becomes
>>> [match[true]]
>>>
>>> the case insensitive option may also help when var or 
>>> [{$:/temp/tiddler}] was provided by the user in case they entered tRue and 
>>> other combinations by mistake.
>>>
>>> Thanks Jeremy
>>> Tony
>>>
>>>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/886c14b0-6519-42e7-91d8-c46c8554d2ea%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mohammad]

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]]" variable=case>
> Process "caseone"
>
><$list filter="[match[casetwo]]" variable=case>
> Process "casetwo"
>
><$list filter="[match[casethree]]" variable=case>
> Process "casethree"
>
>
> 
><$list filter="[match[casetwo]] [match[casethree]]" 
> variable=case>
> Process "casetwo" and "casethree"
>
> 
>
> Regards
> Tony
>
> On Thursday, August 1, 2019 at 3:34:59 AM UTC+10, Mohammad wrote:
>>
>> 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 would say
>>>
>>> [prefix[caseone]suffix[caseone]]
>>>
>>> Now we would say
>>> [regexp[^caseone$]]
>>>
>>> But this Will become which is easier to remember
>>> [match[caseone]]
>>>
>>> The regex example still points us to the best approach for more complex 
>>> tests but match will work for many common cases. 
>>>
>>> I will now abandon only testing the negative in binary comparisons such 
>>> as
>>> [] -[[false]]
>>>
>>> becomes
>>> [match[true]]
>>>
>>> the case insensitive option may also help when var or 
>>> [{$:/temp/tiddler}] was provided by the user in case they entered tRue and 
>>> other combinations by mistake.
>>>
>>> Thanks Jeremy
>>> Tony
>>>
>>>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/71451245-1488-4b3f-9c73-135b65e0c2d6%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[@TiddlyTweeter]

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 
extensively (most "pragma" for instance use regexes within an "AST" (a 
framework that controls them) in applying WikiText).

Regex as a [filter] is interesting and useful, but I'm not sure it can be 
leveraged without slightly better understanding what regex can and can't do.

Important to note is regex has NO understanding of maths at all. YET you 
can use it, for instance, to support a system that needs proper accurate 
dates, including leap years and month days from 1000 to  in both the 
Grgeorian and Julian clanders. But it does NOT do it though calculation. It 
does it through pattern matching only.

Its this apparent weirdness in regex I think that is very confusing if you 
looking for a logical operator that can say "yes" or "the total is". That 
is not its strength and it will confound you thinking it might be (because 
it sort of looks "intelligent"--its actually more like using 
crossword-puzzles).

*So maybe what is perhaps needed most are some basic examples of what regex 
patterns are and how they match example data?*

BTW, the examples you ask about, when they involve matching strings in TW 
(not evaluation or math), are all easily doable via regex.

Thoughts
Josiah



TonyM wrote:
>
> With  *2019-08-01* give  *20190801* (remove delimiters
> or return 
> 2019
> 08
> 01
>
> Do the reverse? add "-" tt position 4 6 8
>
>>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/90579911-41c9-4b24-8444-3bcc6d63aaa5%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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. 
>
> 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 tiddlywiki patterns `{{ }} {{!! << [[ ||` and 
>when they have matching braces extract what is between them
>- Imagine if we could search for the use of templates 
>   `{{something||template}}`
>- Given a keyword find "keyword:" "[[keyword]]" etc...
>- Find keyword pairs eg keyword="value" keyword:"value" keyword:value 
>need to account for ' "" """
>   - Search values and get values (less the keyword)
>- Find the delimiters in use eg [[]] "," "/"
>- Count the number of delimiters eg how many "/" in a title
>
> Any thing which results in a numeric output will have more value than ever 
> with the introduction of maths operators.
>
> Regards
> Tony
>
>
> On Friday, August 2, 2019 at 2:27:35 AM UTC+10, @TiddlyTweeter wrote:
>>
>> 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 that I can explain how to deal with.
>>
>> I'm now thinking about it as there seems to be interest.
>>
>> J.
>>
>>
>> On Thursday, 1 August 2019 18:01:49 UTC+2, Mohammad wrote:

 Josiah,
 I would also appreciate if you could provide examples of common and 
 useful pattern of 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 a Day Using regexp with 
 Tiddlywiki*  :-)

 Cheers
 Mohammad 



 On Thursday, August 1, 2019 at 7:41:53 PM UTC+4:30, @TiddlyTweeter 
 wrote:
>
> 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 plain English *ignoring 
> regex does plain already*.
>  
>
>> 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 brainstorm some 
>> desirable ones.
>>
>
> I'd happily do it. But I need to know what is needed. What is relevant?
>
> TT
>
>>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/3d4c4118-5b00-4e5a-9e3e-c03b27063ac7%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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 tiddlywiki patterns `{{ }} {{!! << [[ ||` and 
   when they have matching braces extract what is between them
   - Imagine if we could search for the use of templates 
  `{{something||template}}`
   - Given a keyword find "keyword:" "[[keyword]]" etc...
   - Find keyword pairs eg keyword="value" keyword:"value" keyword:value 
   need to account for ' "" """
  - Search values and get values (less the keyword)
   - Find the delimiters in use eg [[]] "," "/"
   - Count the number of delimiters eg how many "/" in a title

Any thing which results in a numeric output will have more value than ever 
with the introduction of maths operators.

Regards
Tony


On Friday, August 2, 2019 at 2:27:35 AM UTC+10, @TiddlyTweeter wrote:
>
> 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 that I can explain how to deal with.
>
> I'm now thinking about it as there seems to be interest.
>
> J.
>
>
> On Thursday, 1 August 2019 18:01:49 UTC+2, Mohammad wrote:
>>>
>>> Josiah,
>>> I would also appreciate if you could provide examples of common and 
>>> useful pattern of 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 a Day Using regexp with 
>>> Tiddlywiki*  :-)
>>>
>>> Cheers
>>> Mohammad 
>>>
>>>
>>>
>>> On Thursday, August 1, 2019 at 7:41:53 PM UTC+4:30, @TiddlyTweeter wrote:

 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 plain English *ignoring regex 
 does plain already*.
  

> 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 brainstorm some 
> desirable ones.
>

 I'd happily do it. But I need to know what is needed. What is relevant?

 TT

>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/b4a13c09-492b-4b1c-b4ab-3245551ff6f4%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mohammad]

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 the *search *or 
*prefix *or other filter operator.

--Mohammad




On Thursday, August 1, 2019 at 8:57:35 PM UTC+4:30, @TiddlyTweeter wrote:
>
> 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 that I can explain how to deal with.
>
> I'm now thinking about it as there seems to be interest.
>
> J.
>
>
> On Thursday, 1 August 2019 18:01:49 UTC+2, Mohammad wrote:
>>>
>>> Josiah,
>>> I would also appreciate if you could provide examples of common and 
>>> useful pattern of 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 a Day Using regexp with 
>>> Tiddlywiki*  :-)
>>>
>>> Cheers
>>> Mohammad 
>>>
>>>
>>>
>>> On Thursday, August 1, 2019 at 7:41:53 PM UTC+4:30, @TiddlyTweeter wrote:

 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 plain English *ignoring regex 
 does plain already*.
  

> 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 brainstorm some 
> desirable ones.
>

 I'd happily do it. But I need to know what is needed. What is relevant?

 TT

>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/3454885c-1190-423a-a5ac-f1f71fc66e20%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[@TiddlyTweeter]

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 that I can explain how to deal with.

I'm now thinking about it as there seems to be interest.

J.


On Thursday, 1 August 2019 18:01:49 UTC+2, Mohammad wrote:
>>
>> Josiah,
>> I would also appreciate if you could provide examples of common and 
>> useful pattern of 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 a Day Using regexp with 
>> Tiddlywiki*  :-)
>>
>> Cheers
>> Mohammad 
>>
>>
>>
>> On Thursday, August 1, 2019 at 7:41:53 PM UTC+4:30, @TiddlyTweeter wrote:
>>>
>>> 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 plain English *ignoring regex does 
>>> plain already*.
>>>  
>>>
 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 brainstorm some 
 desirable ones.

>>>
>>> I'd happily do it. But I need to know what is needed. What is relevant?
>>>
>>> TT
>>>


-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/61c1c8b0-fe2d-42b8-9bb2-910d5f43ec43%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[@TiddlyTweeter]

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 its the lack of a broad 
understanding of their ubuiquity that is in the way.

Josiah

On Thursday, 1 August 2019 18:01:49 UTC+2, Mohammad wrote:
>
> Josiah,
> I would also appreciate if you could provide examples of common and useful 
> pattern of 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 a Day Using regexp with 
> Tiddlywiki*  :-)
>
> Cheers
> Mohammad 
>
>
>
> On Thursday, August 1, 2019 at 7:41:53 PM UTC+4:30, @TiddlyTweeter wrote:
>>
>> 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 plain English *ignoring regex does 
>> plain already*.
>>  
>>
>>> 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 brainstorm some desirable 
>>> ones.
>>>
>>
>> I'd happily do it. But I need to know what is needed. What is relevant?
>>
>> TT
>>
>>>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/0ed6146a-2495-4cbe-9257-d8637d1126db%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mohammad]

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 a Day Using regexp with 
Tiddlywiki*  :-)

Cheers
Mohammad 



On Thursday, August 1, 2019 at 7:41:53 PM UTC+4:30, @TiddlyTweeter wrote:
>
> 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 plain English *ignoring regex does 
> plain already*.
>  
>
>> 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 brainstorm some desirable 
>> ones.
>>
>
> I'd happily do it. But I need to know what is needed. What is relevant?
>
> TT
>
>>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/3052dfa7-9e07-4e93-8170-62de5f910c8e%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[@TiddlyTweeter]

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 plain English *ignoring regex does plain 
already*.
 

> 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 brainstorm some desirable 
> ones.
>

I'd happily do it. But I need to know what is needed. What is relevant?

TT

>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/90d86cde-7e88-4acf-85bc-3fbc0cf9513d%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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 brainstorm some desirable ones.

Regards
Tony

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/4c3b7c9d-c52e-44d4-a2c8-8a1337ed46aa%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[@TiddlyTweeter]

>
> 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 seems a bit odd to advance 
"match" when its simply a sub-set in this case.

I'm sure there are useful cases, but that is not one of them.

Josiah

>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/e208769a-4065-41ed-b159-b3b3050ab9d1%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[@TiddlyTweeter]

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 I'm any good at.

I'd like to comment that in one way TW can be seen as a Regex Machine + a 
very good AST.

Regular expressions are frustrating at first as their scope if you never 
used them before. Especially when more complex, they absolutely need 
testing against data because they do not work using procedural logic. 

But they are *the single most powerful tool for text matching and 
manipulation we have.*

I do think that slightly better understanding of regular expressions 
amongst TW users would leverage it better. 

When you understand them they are very economical.

Dimmi (tell me) what would be useful for you to better understand Reggie? 
I'm willing to lay it out.

TT





-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/537930f0-7233-44bc-9960-b28391ab7f0b%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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>
Process "casetwo"
   
   <$list filter="[match[casethree]]" variable=case>
Process "casethree"

   

   <$list filter="[match[casetwo]] [match[casethree]]" 
variable=case>
Process "casetwo" and "casethree"
   


Regards
Tony

On Thursday, August 1, 2019 at 3:34:59 AM UTC+10, Mohammad wrote:
>
> 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 would say
>>
>> [prefix[caseone]suffix[caseone]]
>>
>> Now we would say
>> [regexp[^caseone$]]
>>
>> But this Will become which is easier to remember
>> [match[caseone]]
>>
>> The regex example still points us to the best approach for more complex 
>> tests but match will work for many common cases. 
>>
>> I will now abandon only testing the negative in binary comparisons such as
>> [] -[[false]]
>>
>> becomes
>> [match[true]]
>>
>> the case insensitive option may also help when var or [{$:/temp/tiddler}] 
>> was provided by the user in case they entered tRue and other combinations 
>> by mistake.
>>
>> Thanks Jeremy
>> Tony
>>
>>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/bf9a687c-491a-4022-b4ed-a8618116222e%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mohammad]

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 would say
>
> [prefix[caseone]suffix[caseone]]
>
> Now we would say
> [regexp[^caseone$]]
>
> But this Will become which is easier to remember
> [match[caseone]]
>
> The regex example still points us to the best approach for more complex 
> tests but match will work for many common cases. 
>
> I will now abandon only testing the negative in binary comparisons such as
> [] -[[false]]
>
> becomes
> [match[true]]
>
> the case insensitive option may also help when var or [{$:/temp/tiddler}] 
> was provided by the user in case they entered tRue and other combinations 
> by mistake.
>
> Thanks Jeremy
> Tony
>
>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/22ffa41f-1c21-4b2d-8d66-c1ff23753a1c%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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
[match[caseone]]

The regex example still points us to the best approach for more complex tests 
but match will work for many common cases. 

I will now abandon only testing the negative in binary comparisons such as
[] -[[false]]

becomes
[match[true]]

the case insensitive option may also help when var or [{$:/temp/tiddler}] was 
provided by the user in case they entered tRue and other combinations by 
mistake.

Thanks Jeremy
Tony



-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/5d64d5bd-5f12-4031-aad4-6ee57bbb780a%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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 possible value because ":" is possibly a regex 
value.

`[match[one]]` would still be nicer Support here 


<$list filter="[] ~[[false]]" variable=case>
   <$list filter="[regexp[^false$]]" variable=case>
Do this if no case value
   
   <$list filter="[regexp[^caseone$]]" variable=case>
Process "caseone"
   
   <$list filter="[regexp[^casetwo$]]" variable=case>
Process "casetwo"
   
   <$list filter="[regexp[^casethree$]]" variable=case>
Process "casethree"
   

   <$list filter="[regexp[^casetwo$]] [regexp[^casethree$]]" 
variable=case>
Process "casetwo" and "casethree"
   



Regards
Tony

On Sunday, July 28, 2019 at 10:44:48 AM UTC+10, Mat wrote:
>
> 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 list of desirable tests for you 
>> to match?
>>
>
> 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...
>
> <:-)
>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/f271269c-55c2-4875-b84d-49d5fb6a4063%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mat]

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 list of desirable tests for you 
> to match?
>

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...

<:-)

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/7bb3e3d1-af3d-4fb1-a274-b89c5a54f725%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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 cases where it helps address a 
shortcoming.

If you know regex well I could generate a list of desirable tests for you 
to match?

Regards
Tony

On Sunday, July 28, 2019 at 10:05:33 AM UTC+10, Mat wrote:
>
> 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 group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/5e1cec14-6ebe-4fb0-b0e1-71e2765537dd%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mat]

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 group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/4cc45a41-c695-40b0-8e74-cdebeb96817e%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mohammad]

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 with
>
> filter="[<__x__>prefix[one]suffix[one]]"
>
>
> This do the job!

 

> If we ever get an equals[] operator this would become
> [<__x__>equals[one]]
> Not real yet :)
>
> Regards
> Tony
>
> On Saturday, July 27, 2019 at 7:30:23 PM UTC+10, Mohammad wrote:
>>
>> 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
>>
>> <>
>> <>
>> <>
>> <>
>>
>> The prefix is case sensitive and it is good
>> but it also handle cases like oneWord where one is part of another word!
>>
>> --Mohammad
>>
>>
>> On Saturday, July 27, 2019 at 11:12:56 AM UTC+4:30, TonyM wrote:
>>>
>>> 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 if no case value
>>>
>>><$list filter="[!prefix[::false]]" variable=case>
>>> Do this for every case except empty/false
>>>
>>><$list filter="[prefix[caseone]]" variable=case>
>>> Process "caseone"
>>>
>>><$list filter="[prefix[casetwo]]" variable=case>
>>> Process "casetwo"
>>>
>>><$list filter="[prefix[casethree]]" variable=case>
>>> Process "casethree"
>>>
>>> 
>>><$list filter="[prefix[casetwo]] [prefix[casethree]]" 
>>> variable=case>
>>> Process "casetwo" and "casethree"
>>>
>>> 
>>> Then change add remove as needed for their application
>>>
>>> However in the unlikely case people need to use "nested case statements 
>>> or reuse them, here is a Quick macro version
>>> \define in-cases-of(case-filter)
>>> <$list filter="$case-filter$ ~[[::false]]" variable=case>
>>><$list filter="[prefix[::false]]" variable=case>
>>> Do this if no case value
>>>
>>><$list filter="[!prefix[::false]]" variable=case>
>>> Do this for every case except empty/false
>>>
>>><$list filter="[prefix[caseone]]" variable=case>
>>> Process "caseone"
>>>
>>><$list filter="[prefix[casetwo]]" variable=case>
>>> Process "casetwo"
>>>
>>><$list filter="[prefix[casethree]]" variable=case>
>>> Process "casethree"
>>>
>>> 
>>><$list filter="[prefix[casetwo]] [prefix[casethree]]" 
>>> variable=case>
>>> Process "casetwo" and "casethree"
>>>
>>> 
>>> \end
>>>
>>> <>
>>> Which still needs editing for the specific situation
>>>
>>> CHanges most likely would be only
>>>
>>>- Change the values for caseone casetwo and casethree to those you 
>>>want to use
>>>- Add remove other responses to different case values or 
>>>combinations thereof.
>>>
>>> Additional interesting patterns here
>>>
>>>- The above method of passing filters to a macro as a parameter, 
>>>allows you to pass tiddler content, field content, literal values, 
>>> variable values, 
>>>macronames etc.. which sometimes suddenly results in a macro for one 
>>>purpose suddenly be capable of another purpose.
>>>
>>> In a similar way we can pass a filter to a macro as follows
>>>
>>> \define my-macro(filter)
>>> {{{ $filter$ }}}
>>> {{{ $filter$ ||templatename}}}
>>> \end
>>> or
>>> \define my-macro(filter template)
>>> {{{ $filter$ }}}
>>> {{{ $filter$ ||$templatename$}}}
>>> \end
>>>
>>> Once again all this is untested but based on experience.
>>>
>>> Regards
>>> Tony
>>>
>>>
>>>
>>> On Saturday, July 27, 2019 at 2:39:30 PM UTC+10, Mohammad wrote:

 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 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 included 
> something 
> like this 
> {{invoice-total}}
> where the case test various conditions and generates a result eg if 
> tax applies etc...
>
> However if you do want to make a macro as in your 

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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[] operator this would become
[<__x__>equals[one]]
Not real yet :)

Regards
Tony

On Saturday, July 27, 2019 at 7:30:23 PM UTC+10, Mohammad wrote:
>
> 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
>
> <>
> <>
> <>
> <>
>
> The prefix is case sensitive and it is good
> but it also handle cases like oneWord where one is part of another word!
>
> --Mohammad
>
>
> On Saturday, July 27, 2019 at 11:12:56 AM UTC+4:30, TonyM wrote:
>>
>> 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 if no case value
>>
>><$list filter="[!prefix[::false]]" variable=case>
>> Do this for every case except empty/false
>>
>><$list filter="[prefix[caseone]]" variable=case>
>> Process "caseone"
>>
>><$list filter="[prefix[casetwo]]" variable=case>
>> Process "casetwo"
>>
>><$list filter="[prefix[casethree]]" variable=case>
>> Process "casethree"
>>
>> 
>><$list filter="[prefix[casetwo]] [prefix[casethree]]" 
>> variable=case>
>> Process "casetwo" and "casethree"
>>
>> 
>> Then change add remove as needed for their application
>>
>> However in the unlikely case people need to use "nested case statements 
>> or reuse them, here is a Quick macro version
>> \define in-cases-of(case-filter)
>> <$list filter="$case-filter$ ~[[::false]]" variable=case>
>><$list filter="[prefix[::false]]" variable=case>
>> Do this if no case value
>>
>><$list filter="[!prefix[::false]]" variable=case>
>> Do this for every case except empty/false
>>
>><$list filter="[prefix[caseone]]" variable=case>
>> Process "caseone"
>>
>><$list filter="[prefix[casetwo]]" variable=case>
>> Process "casetwo"
>>
>><$list filter="[prefix[casethree]]" variable=case>
>> Process "casethree"
>>
>> 
>><$list filter="[prefix[casetwo]] [prefix[casethree]]" 
>> variable=case>
>> Process "casetwo" and "casethree"
>>
>> 
>> \end
>>
>> <>
>> Which still needs editing for the specific situation
>>
>> CHanges most likely would be only
>>
>>- Change the values for caseone casetwo and casethree to those you 
>>want to use
>>- Add remove other responses to different case values or combinations 
>>thereof.
>>
>> Additional interesting patterns here
>>
>>- The above method of passing filters to a macro as a parameter, 
>>allows you to pass tiddler content, field content, literal values, 
>> variable values, 
>>macronames etc.. which sometimes suddenly results in a macro for one 
>>purpose suddenly be capable of another purpose.
>>
>> In a similar way we can pass a filter to a macro as follows
>>
>> \define my-macro(filter)
>> {{{ $filter$ }}}
>> {{{ $filter$ ||templatename}}}
>> \end
>> or
>> \define my-macro(filter template)
>> {{{ $filter$ }}}
>> {{{ $filter$ ||$templatename$}}}
>> \end
>>
>> Once again all this is untested but based on experience.
>>
>> Regards
>> Tony
>>
>>
>>
>> On Saturday, July 27, 2019 at 2:39:30 PM UTC+10, Mohammad wrote:
>>>
>>> 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 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 included 
 something 
 like this 
 {{invoice-total}}
 where the case test various conditions and generates a result eg if tax 
 applies etc...

 However if you do want to make a macro as in your example the case 
 structure will still need to know how to handle your array-of-cases

 I would think its more like this;
 \define if-else-test(filter)
 <$list filter="[[$filter$]] ~[[::else]]" variable=case>
 <$list filter="[!prefix[::else]]" 

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mohammad]

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

<>
<>
<>
<>

The prefix is case sensitive and it is good
but it also handle cases like oneWord where one is part of another word!

--Mohammad


On Saturday, July 27, 2019 at 11:12:56 AM UTC+4:30, TonyM wrote:
>
> 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 if no case value
>
><$list filter="[!prefix[::false]]" variable=case>
> Do this for every case except empty/false
>
><$list filter="[prefix[caseone]]" variable=case>
> Process "caseone"
>
><$list filter="[prefix[casetwo]]" variable=case>
> Process "casetwo"
>
><$list filter="[prefix[casethree]]" variable=case>
> Process "casethree"
>
> 
><$list filter="[prefix[casetwo]] [prefix[casethree]]" 
> variable=case>
> Process "casetwo" and "casethree"
>
> 
> Then change add remove as needed for their application
>
> However in the unlikely case people need to use "nested case statements or 
> reuse them, here is a Quick macro version
> \define in-cases-of(case-filter)
> <$list filter="$case-filter$ ~[[::false]]" variable=case>
><$list filter="[prefix[::false]]" variable=case>
> Do this if no case value
>
><$list filter="[!prefix[::false]]" variable=case>
> Do this for every case except empty/false
>
><$list filter="[prefix[caseone]]" variable=case>
> Process "caseone"
>
><$list filter="[prefix[casetwo]]" variable=case>
> Process "casetwo"
>
><$list filter="[prefix[casethree]]" variable=case>
> Process "casethree"
>
> 
><$list filter="[prefix[casetwo]] [prefix[casethree]]" 
> variable=case>
> Process "casetwo" and "casethree"
>
> 
> \end
>
> <>
> Which still needs editing for the specific situation
>
> CHanges most likely would be only
>
>- Change the values for caseone casetwo and casethree to those you 
>want to use
>- Add remove other responses to different case values or combinations 
>thereof.
>
> Additional interesting patterns here
>
>- The above method of passing filters to a macro as a parameter, 
>allows you to pass tiddler content, field content, literal values, 
> variable values, 
>macronames etc.. which sometimes suddenly results in a macro for one 
>purpose suddenly be capable of another purpose.
>
> In a similar way we can pass a filter to a macro as follows
>
> \define my-macro(filter)
> {{{ $filter$ }}}
> {{{ $filter$ ||templatename}}}
> \end
> or
> \define my-macro(filter template)
> {{{ $filter$ }}}
> {{{ $filter$ ||$templatename$}}}
> \end
>
> Once again all this is untested but based on experience.
>
> Regards
> Tony
>
>
>
> On Saturday, July 27, 2019 at 2:39:30 PM UTC+10, Mohammad wrote:
>>
>> 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 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 included something like 
>>> this 
>>> {{invoice-total}}
>>> where the case test various conditions and generates a result eg if tax 
>>> applies etc...
>>>
>>> However if you do want to make a macro as in your example the case 
>>> structure will still need to know how to handle your array-of-cases
>>>
>>> I would think its more like this;
>>> \define if-else-test(filter)
>>> <$list filter="[[$filter$]] ~[[::else]]" variable=case>
>>> <$list filter="[!prefix[::else]]" variable=case>
>>>filter-not-empty do-this for each result
>>> 
>>>   <$list filter="[prefix[::else]]" variable=case>
>>> else do-that
>>>
>>>
>>> 
>>> \end
>>> <>
>>> note: untested
>>>
>>> Regards
>>> Tony
>>>
>>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/8be7f90a-cdc9-4198-820c-24ef2450c769%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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 if no case value
   
   <$list filter="[!prefix[::false]]" variable=case>
Do this for every case except empty/false
   
   <$list filter="[prefix[caseone]]" variable=case>
Process "caseone"
   
   <$list filter="[prefix[casetwo]]" variable=case>
Process "casetwo"
   
   <$list filter="[prefix[casethree]]" variable=case>
Process "casethree"
   

   <$list filter="[prefix[casetwo]] [prefix[casethree]]" 
variable=case>
Process "casetwo" and "casethree"
   

Then change add remove as needed for their application

However in the unlikely case people need to use "nested case statements or 
reuse them, here is a Quick macro version
\define in-cases-of(case-filter)
<$list filter="$case-filter$ ~[[::false]]" variable=case>
   <$list filter="[prefix[::false]]" variable=case>
Do this if no case value
   
   <$list filter="[!prefix[::false]]" variable=case>
Do this for every case except empty/false
   
   <$list filter="[prefix[caseone]]" variable=case>
Process "caseone"
   
   <$list filter="[prefix[casetwo]]" variable=case>
Process "casetwo"
   
   <$list filter="[prefix[casethree]]" variable=case>
Process "casethree"
   

   <$list filter="[prefix[casetwo]] [prefix[casethree]]" 
variable=case>
Process "casetwo" and "casethree"
   

\end

<>
Which still needs editing for the specific situation

CHanges most likely would be only

   - Change the values for caseone casetwo and casethree to those you want 
   to use
   - Add remove other responses to different case values or combinations 
   thereof.

Additional interesting patterns here

   - The above method of passing filters to a macro as a parameter, allows 
   you to pass tiddler content, field content, literal values, variable values, 
   macronames etc.. which sometimes suddenly results in a macro for one 
   purpose suddenly be capable of another purpose.

In a similar way we can pass a filter to a macro as follows

\define my-macro(filter)
{{{ $filter$ }}}
{{{ $filter$ ||templatename}}}
\end
or
\define my-macro(filter template)
{{{ $filter$ }}}
{{{ $filter$ ||$templatename$}}}
\end

Once again all this is untested but based on experience.

Regards
Tony



On Saturday, July 27, 2019 at 2:39:30 PM UTC+10, Mohammad wrote:
>
> 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 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 included something like 
>> this 
>> {{invoice-total}}
>> where the case test various conditions and generates a result eg if tax 
>> applies etc...
>>
>> However if you do want to make a macro as in your example the case 
>> structure will still need to know how to handle your array-of-cases
>>
>> I would think its more like this;
>> \define if-else-test(filter)
>> <$list filter="[[$filter$]] ~[[::else]]" variable=case>
>> <$list filter="[!prefix[::else]]" variable=case>
>>filter-not-empty do-this for each result
>> 
>>   <$list filter="[prefix[::else]]" variable=case>
>> else do-that
>>
>>
>> 
>> \end
>> <>
>> note: untested
>>
>> Regards
>> Tony
>>
>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/ab565b86-8bd7-4321-b463-3452242828fc%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mohammad]

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 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 included something like 
> this 
> {{invoice-total}}
> where the case test various conditions and generates a result eg if tax 
> applies etc...
>
> However if you do want to make a macro as in your example the case 
> structure will still need to know how to handle your array-of-cases
>
> I would think its more like this;
> \define if-else-test(filter)
> <$list filter="[[$filter$]] ~[[::else]]" variable=case>
> <$list filter="[!prefix[::else]]" variable=case>
>filter-not-empty do-this for each result
> 
>   <$list filter="[prefix[::else]]" variable=case>
> else do-that
>
>
> 
> \end
> <>
> note: untested
>
> Regards
> Tony
>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/52a0edc2-46f7-4ee4-850b-e810ba5008c1%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[A Gloom]

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 web visit 
https://groups.google.com/d/msgid/tiddlywiki/c6906152-a5cb-4532-a4eb-cfb48e13666c%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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 included something like 
this 
{{invoice-total}}
where the case test various conditions and generates a result eg if tax 
applies etc...

However if you do want to make a macro as in your example the case 
structure will still need to know how to handle your array-of-cases

I would think its more like this;
\define if-else-test(filter)
<$list filter="[[$filter$]] ~[[::else]]" variable=case>
<$list filter="[!prefix[::else]]" variable=case>
   filter-not-empty do-this for each result

  <$list filter="[prefix[::else]]" variable=case>
else do-that
   
   

\end
<>
not: untested

Regards
Tony

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/1cf05827-3ae6-4171-a9f2-db625af4d052%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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="[] ~[[::else]]" variable=case>
<$list filter="[!prefix[::else]]" variable=case>
*filter**-not-**empty *do-this

  <$list filter="[prefix[::else]]" variable=case>
*else *do-that
   
 
Note: untested

Regards
Tony

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/8bb3aa5f-223c-44ba-9fe7-cc4aa3726255%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[Mohammad]

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
   - filter is empty go for emptyMessage




--Mohammad


On Friday, July 26, 2019 at 8:50:31 AM UTC+4:30, 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 use the 
> emptyMessage to deal with the null case.
>
> If the Null case response requires multiple lines of wiki text it gets a 
> little messy
>
> \define macrodef()
> If condition not met
> \end
>
>
> <$list filter="condition" emptyMessage=<> >
> If Condition met
> 
> The macro def must be at the top and it is removed from the list widget
>
>
> OR
> <$list filter="condition" emptyMessage="""
>
> If condition not met
> """>
> If Condition met
> 
> This makes me nervous :)
>
> So I developed this method/pattern
> <$list filter="[is[current]tagging[]] ~[[::false]]" variable=result>
><$list filter="[prefix[::]]" variable=case>
> Do this if <>
>
><$list filter="[!prefix[::]]" variable=case>
> Process tiddler "<>"
>
> 
> Using the unlikely tiddler title "::false" to flag the empty set condition.
> In this case the null *case* is executed once and the "no null case" as 
> many times as needed.
>
> *And did I mention "case"?*
>
> This structure also allows us to build a CASE structure with a default 
> behaviour.
>
> That is if a variable or field contains one of a number different values, 
> and you wish to respond differently for each
>
> <$list filter="[] ~[[::false]]" variable=case>
><$list filter="[prefix[::false]]" variable=case>
> Do this if no case value
>
><$list filter="[prefix[caseone]]" variable=case>
> Process "caseone"
>
><$list filter="[prefix[casetwo]]" variable=case>
> Process "casetwo"
>
><$list filter="[prefix[casethree]]" variable=case>
> Process "casethree"
>
> 
><$list filter="[prefix[casetwo]] [prefix[casethree]]" 
> variable=case>
> Process "casetwo" and "casethree"
>
> 
>
> With the mathematics operators 
>
> More will be possible?
>
> Regards
> Tony
>
>
>
>
>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/2390a2fb-babb-4403-98ad-42ea6ad92532%40googlegroups.com.

[tw5] Re: Interesting Code Patterns? Handling the emptyMessage condition in the ListWidget Body, a CASE structure, complex formulas

[TonyM]

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 use the 
> emptyMessage to deal with the null case.
>
> If the Null case response requires multiple lines of wiki text it gets a 
> little messy
>
> \define macrodef()
> If condition not met
> \end
>
>
> <$list filter="condition" emptyMessage=<> >
> If Condition met
> 
> The macro def must be at the top and it is removed from the list widget
>
>
> OR
> <$list filter="condition" emptyMessage="""
>
> If condition not met
> """>
> If Condition met
> 
> This makes me nervous :)
>
> So I developed this method/pattern
> <$list filter="[is[current]tagging[]] ~[[::false]]" variable=result>
><$list filter="[prefix[::]]" variable=case>
> Do this if <>
>
><$list filter="[!prefix[::]]" variable=case>
> Process tiddler "<>"
>
> 
> Using the unlikely tiddler title "::false" to flag the empty set condition.
> In this case the null *case* is executed once and the "no null case" as 
> many times as needed.
>
> *And did I mention "case"?*
>
> This structure also allows us to build a CASE structure with a default 
> behaviour.
>
> That is if a variable or field contains one of a number different values, 
> and you wish to respond differently for each
>
> <$list filter="[] ~[[::false]]" variable=case>
><$list filter="[prefix[::false]]" variable=case>
> Do this if no case value
>
><$list filter="[prefix[caseone]]" variable=case>
> Process "caseone"
>
><$list filter="[prefix[casetwo]]" variable=case>
> Process "casetwo"
>
><$list filter="[prefix[casethree]]" variable=case>
> Process "casethree"
>
> 
><$list filter="[prefix[casetwo]] [prefix[casethree]]" 
> variable=case>
> Process "casetwo" and "casethree"
>
> 
>
> With the mathematics operators 
>
> More will be possible?
>
> Regards
> Tony
>
>
>
>
>

-- 
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 
https://groups.google.com/d/msgid/tiddlywiki/3f204f5f-7568-40d6-819a-519d0287fcf5%40googlegroups.com.