Hi Tobias
On Tuesday, 27 October 2015 15:19:13 UTC+2, Tobias Beer wrote:
>
>
> 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]] ]] }}}
>
>
Yep -- this doesn't work (I've been testing in the filter tab of advanced
search) -- there should be some convention for doing so. I think to get
this to work, any list containing items with spaces would have to be saved
into a variable or macro, then referenced like this:
append:3<myvariable>
> 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 filter operations that yield duplicates. So
> filters actually operate on or rather produce *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.
>
I've never used lists with duplicates for anything -- the usage cases I
have needed were effectively other 'tags' fields for building applications
(thus reserving the 'tags' field for user tags.) This avoids the necessity
of using multiple fields for the purpose, although often I use a single
field with different single item values. It was Jed whom insisted that such
lists should be handled -- I, therefore, avoided enforcing single instances
of an item in any of my filters (although the core functions used often do
so.)
The best fix would involve removing the special treatment of the 'tags' and
'list' field in the core -- their behaviour then implemented with standard
list operations. This would permit the core functions to allow multiple
instances of an item.
>
> {{{ 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
>
> The list can be forced back to a set by appending another run, for example
+sort[] -- if you try and append an array of items several times, you only
ever get 2 copies, as each time the append[] is run, any previous
duplicates are removed at the beginning of the subsequent run. An
explanation with the example would at least explain this behaviour.
regards
--
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 tiddlywiki+unsubscr...@googlegroups.com.
To post to this group, send email to tiddlywiki@googlegroups.com.
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/12b40d2d-48cc-4c56-b226-05f215e97b46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
