Hi Metabele, > I have not managed to track down where in the core uniqueness gets > imposed. As Jed points out, the StingifyList function is one place, but > there appear to be others. An index in a data dictionary can be filled with > multiple item values, however, when operations are carried out on that > list, some operations impose uniqueness whilst others do not. >
It's solely in the tag handling capacities... which are independent of any new list-handling capacities, possibly overlapping in capabilities / codebase. Nothing forces new code to make use of stringifyList. In fact, I just realized that being to quick about it means trouble. For example, using the filter parameter with the list widget returnes what? A stringified list!! Well, what if I do *limit[1]* hoping to get just a title, I won't. So, I made a pull request that remedies the situation where I do not want any stringifyList of the filter output, but a plain string instead: *#2035 parameter "format" for set widget * https://github.com/Jermolene/TiddlyWiki5/pull/2035 > My widgets do not impose uniqueness, other than when core functions are > implicitly or explicitly called which do so. However, I have made little > effort to handle multiple instances of a value -- my filters will always > use the first instance of an item as the marker. > Obviously this is necessary so long as one cannot more specific about it, perhaps using refering to a numerical index at that point rather than a named element. Once the core has been modified to correctly handle multiple instances of > the same item, filters can be modified or new filters written to handle the > new usage cases. > I'm not exactly sure which filters are greedy this way or which allow duplicates. A quick test has me think filters always return a SET of tiddlers, never a list (allowing duplicates, e.g try: {{{ foo foo foo }}} Now this means that we are practically barred from using filters whenever we want to do list management that does allow duplicates. It makes sense under the assumption that filters act on tiddler titles, but what about those that don't? Currently, I believe that list management (even in its current form) should > be brought into operation as soon as possible. This will enable most usage > cases for user lists, and experience will be gained in the handling of > lists before finalising their management. > Surely, automating stuff via lists is one thing that makes all the power of TiddlyWiki. The more capabilities we get there, the easier things will be and the broader the general spectrum of things that can be done. I have written a couple of new filters to further extend what is possible > with list management -- a couple more are necessary (especially a > 'sortby[]' filter -- that is: sort a list of items in the order of another > list.) I have also added an '$index=' attribute to the ActionListops widget > to enable manipulation of data dictionary indexes (and modified a couple of > my filters to work with them.) > Fantastic, looking forward to seeing that in action. Perhaps, at some point, I don't know if you do, but if you get to push that to some GitHub repo, it would be easier to communicate around the code. 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/95b97b86-9759-4064-8d97-55abcad79065%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
