Mohammad
- There are two tiddlers sample and population
- the population tiddler has a list field with a b c as field value
- the sample tiddler has a list field with only b as field value
<$list filter="[list[sample]]+[list[population]]">
</$list>
---
<$list filter="[list[population]]+[list[sample]]">
</$list>
TonyM
The its not quite an and without parentheses.
[list[sample]] +[list[population]]
The give the results I expect because the + and - prefixes operate on the list fed to it so far.
[list[sample]] [list[population]]
Would give you the content of both lists after removing duplicates. This is I think more like the and you perceive.
The plus says members of first list and tests each title and passes only titles that are also found in the second list.
Using a negative would say list members of the first list but remove those in the second list ie do not pass on those found in the second list.
This is in part due to the filter nature each run follows the previous one and acts on the result of the previous run if you use - + or ~
Filters typically reduce the set first presented to a subset according to its conditions.
For this reason the order is esentiial because one is the source the second is an operation ibn the members in the source.
On way to look at is the second list has a leading operator so it will perform an operation on the list so far.
Regards
Tony
Mohammad
On Friday, December 20, 2019 at 2:12:27 PM UTC+3:30, TonyM wrote:
MohammadThe its not quite an and without parentheses.
[list[sample]] +[list[population]]
The give the results I expect because the + and - prefixes operate on the list fed to it so far.
[list[sample]] [list[population]]Would give you the content of both lists after removing duplicates. This is I think more like the and you perceive.
The plus says members of first list and tests each title and passes only titles that are also found in the second list.
Mohammad
TiddlyTweeter
It seams I don't know how list works or it is a bug
It is a problem with list filters sometimes working out IF an issue is a bug OR lack of understanding.
In theory it should be possible to present a logical table of filter operations showing scope?
But perhaps not? Not sure! But I have never seen one.
What I have noticed is that skilled programmers too have trouble sometimes with list filters.
I am not a programmer and my approach to list filters is largely "stab-in-the-dark".
Just notes
TT
TonyM
I will give a better comment at my desktop tomorrow.
Each run with selection modifiers and selection constructors are interpreted sequentially and also alter the result. Its more like the dos or Linux filters such as pipe input and output.
For example we can't use parenthesis to change order as we can in maths.
Its just a different way to conceptualize it and filters are well suited to handling sets (of titles).
I think a conceptual overview would help that I am now more qualified to write than I was before.
Regards
Tony
PMario
What I have noticed is that skilled programmers too have trouble sometimes with list filters.
Filter Formal Grammar
- FilterOperator: after
- FilterOperator: all
- FilterOperator: backlinks
- FilterOperator: before
- FilterOperator: bf
- FilterOperator: butfirst
- FilterOperator: butlast
- FilterOperator: commands
- FilterOperator: each
- FilterOperator: eachday
- FilterOperator: field
- FilterOperator: first
- FilterOperator: get
- FilterOperator: has
- FilterOperator: indexes
- FilterOperator: is
- FilterOperator: last
- FilterOperator: limit
- FilterOperator: links
- FilterOperator: list
- FilterOperator: listed
- FilterOperator: modules
- FilterOperator: moduletypes
- FilterOperator: next
- FilterOperator: nsort
- FilterOperator: nsortcs
- FilterOperator: nth
- FilterOperator: plugintiddlers
- FilterOperator: prefix
- FilterOperator: previous
- FilterOperator: regexp
- FilterOperator: removeprefix
- FilterOperator: removesuffix
- FilterOperator: rest
- FilterOperator: reverse
- FilterOperator: sameday
- FilterOperator: search
- FilterOperator: shadowsource
- FilterOperator: sort
- FilterOperator: sortcs
- FilterOperator: suffix
- FilterOperator: tag
- FilterOperator: tagging
- FilterOperator: tags
- FilterOperator: title
- FilterOperator: untagged
... It is an "organically grown" language. That means, whenever there was a strong demand, which made sense, something has been implemented, that solved the specific problem.
On the way, some "syntax" decisions had to be made. Sometimes it turned out (after a year or 2), that "the other possibility" would have been better, in the long run. That's why the filter syntax isn't 100% consistent. ... Because ...
TiddlyTweeter
... It is an "organically grown" language. That means, whenever there was a strong demand, which made sense, something has been implemented, that solved the specific problem.
... That's why the filter syntax isn't 100% consistent. ... Because ... Backwards compatibility trumps consistency!! - always
As a result our "filter language" is a little bit more complex, as it could be ;)
Q: Is it possible to logically depict the filter Operators inter-sequencing?
