Hi Matabele,
> I see, so you are required to specify the operand using text-references or
>> variables for multiple items.
>>
>
>
Not a requirement -- a simple list such as [one two [[and three]]] also
> works
>
I don't think so. This does not work, and I sure did not expect it to:
{{{ [list[!!x]append:3[one two [[and three]] ]] }}}
I didn't choose this convention -- this is standard syntax for references
> inside filter expressions -- if the list were referenced this should also
> be:
>
> filter="[list{mytext!!reference}prepend{...
>
> I imagine the core list filter was designed before allowing text-reference
and variable substitution and so we're stuck with that now.
> Aha -- I haven't done any tests on these -- should this be append === [],
> in this case?
I would take a close look at *parseStringArray* and then see what to
expect, maybe if length == 0?
{{{ [list[!!x]append:3{!!y}] }}}
>
>
That's due to the triple ]]] after the bbbb -- the item gets read
> as aaaa bbbb]
>
Good catch. However, actually, it's not. Even removing the last superfluous
bracket which gets eaten ...interesting as that is ...we still end up with
*mumble* showing up twice on the list.
I have not enforced single instances of items in any of the filter
> operators (although they were designed with single instances in mind.) Many
> operations currently enforce this, for example appending another run --
> it's easy to do but I'm not sure if this is the best way to go. Rather,
> this default behaviour of lists may need modification, or at least this
> behaviour should be optional, as there is a need for repeat items in many
> types of list.
>
I agree that both have their uses, but — correct me if I'm wrong — so far,
I have not encountered any "list" with duplicates... so filters actually
operate on sets for the time being. In other words, I would not introduce
true "lists" by virtue of a single new filter. If those were admissible by
default, I think there should be core support for that no matter which
filter is being interpreted, e.g.
{{{ foo [list[!!bar]+] }}}
...and *+* indicating that duplicates are allowed in the operation that
joins the two.
One of my examples clearly displays this behaviour -- when first appended,
> multiple instances of an item are permitted, on the first update, the list
> becomes collapsed to single instances (due to the + before the next run.)
Not sure which one you mean, but I think if only for testing purposes, you
should...
1. set up examples with duplicate entries
2. define clearly what is expected to happen by default
- I think the default should be to not allow duplicates, as it is atm
Best wishes,
— tb
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" 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/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/14006bb4-a5e7-49f8-b714-f71f1a4d62c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
