Thinking through my historic pain points and where I’ve discussed the need for some kind of storing variable (this thread for example), the way it felt is that only having a single variable (currentTiddler) within the filter was the limit I was trying to overcome.
I’m realizing that I actually had something even more ambitious in mind. This veers off this topic a little bit, but list has always been 1-dimensional in nature - it exposes a single variable, and so other computed values need to be re-calculated within the loop of the widget. If we are filtering real tiddlers then we have syntax shortcuts and efficiencies using the {!!field} notation meaning I can sort by or filter on a field value, but we can’t do that by computed values that are also like properties of the <<currentTiddler>> “object” / record.
And then what if we let these pseudo-fields map within the widget? We kind of get to something more like a SQL situation where the output has “rows” and “columns”. Most of the time I use <$list> it’s within a <table> so this feels very natural.
Today example: Producing a list of tiddlers sorted by their length with both name and computed value put a filter and sort just to show comparison to pseudo-code below.
<$list filter="[prefix[A]] :filter[get[text]length[]compare:number:gt[20]] :sort:number[get[text]length[]]">
<<currentTiddler>>: <$text text={{{ [<currentTiddler>get[text]length[]] }}}/><br>
</$list>
One of the things I’m trying to illustrate here is that get[text]length[] is run not only multiple times within the filter, but then for each entry within the list widget. If that piece is “expensive” / “slow” then this is not ideal.
Pseudo-code below: Storing a computed value in the filter, and then spitting it out of the list widget along with the <<currentTiddler>> variable. I’ll use the word store instead of let to acknowledge that these really do different things.
<$list filter="[prefix[A]] :store:length[get[text]length[]] :filter[<length>compare:number:gt[20]] :and[sort<length>]">
<<currentTiddler>>: <<length>><br>
</$list>
What I’m trying to show in the above is using in-filter notation to store the computed values somewhat as properties of the currentTiddler variable, so that they can be used like they are. It might even be interesting if the syntax was <!!length> in the filter and <<!!length>> within the widget just to illustrate the near-field-like usage.
Maybe this is entirely separate from “multi-valued-variables” but I think there’s some overlap. The above actually doesn’t require variables to be multi-value, so maybe they can be both done with different names.