split agglomerates

[Jean-Pierre Rivière]

Toying with filters, I discovered that the split operator agglomerates its results when ist operates on successive titles.

for instance : {{{ [enlist[a1^a2 b1^b2 c1^c2]split[^][]first[]] }}}

results in a1 not in a1, b1, c1

a sufilter dos not change anything:

<$vars sf="[split[^]dump[]first[]]">

{{{ [enlist[a1^a2 b1^b2 c1^c2]subfilter<sf>] }}}

</$vars>

In fact, in each case, after split, the filter values are a1, a2, b1, b2, c1, c2.

could there be a way to have [a1, a2], [b1, b2], [c1, c2] from enlist[a1^a2 b1^b2 c1^c2] ?

let's use sortsub and a little input set to see that what I am asking for may not be that impossible.

<$vars sf="[split[^]dump[]last[]]">

{{{ [enlist[a1^22 b1^28 c1^14]sortsub<sf>] }}}

</$vars>

reults in c1^14, a1^22, b1^28

which demonstrate that here split produces things like c1, 14 on which split act upon. exactly what I wanted to achieve with subfilter.

-- 

Jean-Pierre

[Mark S.]

It's often the case that we need two nested listwidgets to break down the results the way we want. In your example, everything is split by ^, but then it picks the first item from the resulting list (a1).  You could instead split by space, send the result to an inner loop, and then split by ^ .

But in this case, you could use splitregexp :

{{{ [enlist[a1^a2 b1^b2 c1^c2]splitregexp[\^\w\w]] }}}

a1,  b1, c1

[TW Tones]

Jean-Pierre;

I am not sure about your requirement, but try these

<$list filter="[enlist[a1^a2 b1^b2 c1^c2]]">

   {{{ [<currentTiddler>split[^]first[]] }}}

</$list>

<hr>

<$list filter="[enlist[a1^a2 b1^b2 c1^c2]]">

   <$list filter="[<currentTiddler>split[^]first[]]">

   </$list>

</$list>

<hr>

<$list filter="[enlist[a1^a2 b1^b2 c1^c3]split[^]]">

</$list>

<hr>

<$list filter="[[a1^a2 b1^b2 c1^c3]split[ ]split[^]]">

</$list>

I was recently considering a similar problem, when someone was questioning nesting list widgets, when I realised the $list with filters can act as gosub, while, do until etc... so nesting them is by definition sometimes a logical requirement depending what you are trying to achieve with your filters. Nesting is not easy or possible in many cases with triple curly braces.

Regards

Tones

[Jean-Pierre Rivière]

Thank you Mark! This is a clever trick. Definitely worth remembering.

[Jean-Pierre Rivière]

Nestling, in such a way anyway, is something I had not thought about.

In fact, this is only a part of the pipeline. Can I get back a united output afterwards? I'll experiment and if I'm at loss, I'll post again.

A question remains for me: Why is "split + last" apparently working on so different data when called by sortsub or subfilter? Aren't they just calling a filter? What is causing the diffirence? I think it would be wise and good for me to understand what cause the difference in behavior of such similar patterns.

regards,

-- 

Jean-Pierre

[Saq Imtiaz]

Sortsub applies a filter in turn to each input title separately. The docs do mention this I believe. So the input to the filter each time is a single title.

Subfilter applies a filter once with the input being a title list of all input titles.

[Jean-Pierre Rivière]

Thank you. The doc, at subfilter, does clearly states what filter does. 

The examples fail to make clear of this distinction for subfilter. In fact, they are rather not too much helping.

The first one is 

[subfilter[one two three]addsuffix[!]]

producing 

• one!
• two!
• three!

and we can achieve the very same results with

[enlist[one two three]addsuffix[!]]

This is not very demonstrative.

I suggest these ones:

\define two-wanted() [compare:string:eq[two]addsuffix[*]]

<<.operator-example 1 "[subfilter[one two three]addsuffix[!]]">>

<<.operator-example 1.1 "[enlist[one two three]addsuffix[!]]">>

<<.operator-example 1.2 "[enlist[one two three]subfilter<two-wanted>]">>

<<.operator-example 1.3 "[enlist[one two three]compare:string:eq[two]addsuffix[*]]">>

<<.operator-example 1.4 "[enlist[one two three]filter<two-wanted>]">>

showing that subfilter, finally, is just a nice way to put a name on a sequence of filter operations, for better clarity. 1.2 and 1.3 have the same output: "two*" whereas that of 1.4 is "two"k

In general, the operator of similar effect would gain from comparison like such.