filter syntax

[chris...@gmail.com]

Is there a canonical explanation or definition of the <<list
filter ...>> syntax anywhere? The impression I get from the code is
that what's there is incomplete. I've seen the excellent introduction
at http://lewcid.org/2007/10/23/how-to-list-tiddlers-by-tags-the-filter-tipped-way/

Has anyone written down some plans or is it going to evolve?

The questions that come to my mind are:

* the current syntax appears to do unions, are their plans for
intersections, or complex boolean combinations? I don't have any ideas
on how to do that one.
* the current syntax can list tiddlers by name or tag, what else is
being considerd? I'd like something generic like this:

[<aggregate filter type>[arguments]]

so you get

[tag[myfavoriteplugin]] ==> all tiddlers with tag myfavoriteplugin
[by_name_re[^Foo]] ==> all tiddlers with name beginning 'Foo'
[by_tag_re[^my]] ==> all tiddlers with tag beginning 'my'

This is an issue for me at the moment as I'm trying to come up with a
way to map client side filtering language to server side filter
queries (i.e. given a URL on a server that returns a list of tiddlers,
how to filter that list based on some query).

Thanks.

[FND]

> Is there a canonical explanation or definition of the <<list
> filter ...>> syntax anywhere?

Nothing canonical - Saq's blog post (also linked to from the community
wiki*) is probably the best resource so far.

> Has anyone written down some plans or is it going to evolve?

Several potential enhancements have been discussed.
I believe Jon is working on that now:
http://tinyurl.com/24pryx
(http://groups.google.com/group/TiddlyWikiDev/browse_thread/thread/611a7f2b5ff29dfc/)

Extending the filtering capabilities would certainly be very useful.

-- F.

[Martin Budden]

"* the current syntax appears to do unions, are their plans for
intersections, or complex boolean combinations? I don't have any ideas
on how to do that one."

Each filter element acts on the current list of tiddlers. So eg
[tag[systemConfig]] will add all the systemConfig tagged tiddlers to
the list. Appending [-tag[translations]] will remove any tiddlers
tagged with translation from the current list. So boolean operations
etc do not exist.

Martin

[chris...@gmail.com]

On Feb 19, 2008, at 3:30 PM, Martin Budden wrote:

Each filter element acts on the current list of tiddlers. So eg
[tag[systemConfig]] will add all the systemConfig tagged tiddlers to
the list. Appending [-tag[translations]] will remove any tiddlers
tagged with translation from the current list. So boolean operations
etc do not exist.

From a standpoint of theory and long term vision, not necessarily
current implementation:

Can you define "current list" more completely? Is that:

* the set of Tiddlers on which <<list>> is operating at the start and
that set is the source for all filters

OR

* the set of Tiddlers extant after the last filter operation (in this
<<list>>)

And can you be more explicit about how ordering works in the list of
filters?

Thanks.

[Lyall]

What would be nice is if the tag[tagText] was actually tag[regexp],
where a simple regexp is the same as tagText.

That way, I could do something like [tag [Encrypt\([^)]*\)]] to find
all the tiddlers that have Encrypt(anytext) as a tag.

...Lyall

[Martin Budden]

Chris,

the list is the set of tiddlers extant after the last filter operation, eg

[[Getting Started]]

list contains one tiddler, "Getting Started"

[[Getting Started]] [tag[systemConfig]]

list contains "Getting Started" tiddler and all systemConfig tiddlers

List is ordered and items added/removed as "recipe" is parsed right to left

Martin

[Eric Shulman]

> List is ordered and items added/removed as "recipe" is parsed right to left

"right to left"???

That would seem counter-intuitive, vis-a-vis this usage:

[tag[systemConfig]] [-tag[systemConfigDisable]]

* first get all systemConfig tiddlers,
* then remove systemConfigDisable tiddlers

-e

[Martin Budden]

No, other right!

Sorry my mixup. I meant to say left to right.

Martin

[chris...@gmail.com]

On Feb 21, 4:01 pm, "Martin Budden" <mjbud...@gmail.com> wrote:
> the list is the set of tiddlers extant after the last filter operation, eg
>
> [[Getting Started]]
>
> list contains one tiddler, "Getting Started"
>
> [[Getting Started]] [tag[systemConfig]]
>
> list contains "Getting Started" tiddler and all systemConfig tiddlers

If I did

[[Getting Started]] [tag[systemConfig]] [-tag[systemConfig]]

is the result then solely "Getting Started" or is it all the tiddlers
(everything tagged with systemConfig and everything not tagged with
systemConfig)?

I'm confused if '-' means 'remove' or 'not'. If it means remove, the
code I checked in for TiddlyWeb yesterday is broken, but easy to fix.
What I'm trying to get from this conversation is a reasonable but
constrained set of test cases.

I feel very much like I'm missing some key piece of reference
material. The only reference I'm aware of is the core Tiddlywiki code,
and that code doesn't yet implement '-'. And then there's the tests
that Mr. Lister is doing, how do they fit in?

Thanks.

[Martin Budden]

Chris,

[[Getting Started]] [tag[systemConfig]] [-tag[systemConfig]]

results in solely [[Getting Started]]

Unfortunately this has not all been written down.

Jon Lister's tests are for his client-side implementation of the
filtering mechanism.

Martin

[chris...@gmail.com]

On Feb 22, 8:44 am, "Martin Budden" <mjbud...@gmail.com> wrote:
> Chris,
>
>   [[Getting Started]] [tag[systemConfig]] [-tag[systemConfig]]
>
> results in solely [[Getting Started]]

Right on, that helps clarify things for me.

I'm considering a ! syntax of some kind that makes it possible to say
"the set of tiddlers that is the opposite of what would result from
this single rule", but I'll hold off that for a while.

> Jon Lister's tests are for his client-side implementation of the
> filtering mechanism.

Presumably filterTiddlers(), the bag filtering in TiddlyWeb and Jon's
stuff are all filtering tiddlers so it might make sense to have the
semantics (and maybe semantics) of filtering unified across those
three areas?

[Marc J. Cawood]

On Feb 21, 5:42 am, Lyall <Lyall.Pea...@gmail.com> wrote:
> What would be nice is if the tag[tagText] was actually tag[regexp],
> where a simple regexp is the same as tagText.

I would suggest that we employ /.../ to denote a regex. That way
"simple" use cases just look for the tag "Project1" with
[tag[Project1] and advanced users could do [tag[/Project[0-9]/]...

Hmmm, looks like square brackets are going to be a problem...