Hi I have added another listops filter: -- the move[] filter moves the marker tiddler forward or backward the specified number of places in the list.
I have also done a little more work on the documentation -- this may be found here <http://http;//listops.tiddlyspot.com/>. regards On Sunday, 18 October 2015 19:34:29 UTC+2, Matabele wrote: > > Hi > > I have published my efforts to Github via a pull request to the Master > repo: https://github.com/Jermolene/TiddlyWiki5/pull/2037 > > We can now continue our discussion over there and, I hope, polish up the > code :-) > > Some help with documentation would be welcomed (anybody?) -- not my > strongpoint. I have written some documentation to explain the basics, which > I have made available here <http://listops.tiddlyspot.com/>. > > regards > > On Saturday, 17 October 2015 17:11:53 UTC+2, Tobias Beer wrote: >> >> 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 mostly in the tag handling... which is 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 referencing 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/847ce971-7522-4499-9e86-7717c901a575%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
