Hi Jeremy, > The "tagging" filter can indeed be pretty slow. The mechanism does quite a > bit of caching, but there's still a lot of computation going on. I think > there's still considerable scope for optimisation in the implementation. >
As you know, it is not only about the "tagging" filter. Actually, I prefer using fields instead of tags for the view templates and the <$list> and <$count> widgets inside. > The arrangement you suggest of letting authors compose complex filter > operations with shared partial results has been on my mind too. My thoughts > are around extending widget variables so that we handle lists of values as > well as single valued strings. Then we'd add: > > * <<variable name>> within filters to reference a list in a widget > variable. A minus sign would remove the elements of the specified list: > -<<myList>> > * A new variant of the <$set> widget that can set a variable to the > results of a filter expression > * Perhaps a wikitext syntax for these assignments: > > \list variableName [[filter expression]] > I'm looking forward to see your solution. Jeremy, I thing we should really think about just ONE notation for > variables. Maybe different scopes, but just one type of notations. > At the moment we have at least 3 I know of: > > 1. $var$ - macro parameters > > > 1. $(var)$ - those set with <$set> > > > 1. <<var>> - those set with <$list> > > Additionally <<var>> could as well be a macro called "var". I think this > is by far too much. +1. When I look at the shadow tiddlers to understand how they work, I find the variables very confusing. Best wishes, Alberto -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywikidev. For more options, visit https://groups.google.com/groups/opt_out.
