Provide an index value in lists

[AnthonyMuscio]

When using the proposed range and indices we will now have a quick and easy way to access tiddlers or fields that have numbers in them.

Have we a method available to users (I do not think so) to generate these? like an increment?

This would allow the the creation of the type of content the range and indices[5] filters would be good at finding.

By way of an example Lets say I have 20+ tiddlers, and three sort fields on each. Perhaps I could use drag and drop to order them, then make a button with list to display them in this order and update a sort field with that number.

I could drag and drop reorder them, again and set a second order field, and again for a third.

Now I can use sort[sort-field1] to use the first order, or sort[sort-field2] and sort[sort-field3]

The Best solution?

I would think implicitly or explicitly providing a variable to each iteration of a list item.

Note this is not simply a count as can be achieved with an ordered list, but an actual value that can be used. Inside the list. I am not sure if this could be valid in the set statement use of filter but perhaps the final value could be available eg <<namecount>> within the <$set></$set>

Implicit Or not stated, just available in the widget

<$list filter="[tag[test]]">
<<index>>. <<currentTiddler>><br>
</$list>

Result

0. 1st item
1. 2nd item
2. 3rd item

<$list filter="[tag[test]]">
<<item>>. <<currentTiddler>><br>
</$list>

1. 1st item
2. 2nd item
3. 3rd item

explicit We can name the variable to contain the index, item or count.

<$list filter="[tag[test]]" indexvar="var-name">
<<var-name>>. <<currentTiddler>><br>
</$list>

0. 1st item
1. 2nd item
2. 3rd item

<$list filter="[tag[test]]" itemvar="var-name">
<<var-name>>. <<currentTiddler>><br>
</$list>

1. 1st item
2. 2nd item
3. 3rd item

In a similar vein we could just return a count variable that is the total at the end. so we need not have separate set of list functions, just to count something. Even better would be if the last item, count or index would be available outside the list. This may be a good reason for explicitly named variables.

[EvanBalster]

Hello, Anthony —

This is a feature I'd also like to see in the future, possibly in a second type of list widget.

The big challenge with implementing this function is that it would slow TiddlyWiki down substantially because any change in variables forces content to be re-rendered. (I've done some investigation into ways of optimizing TiddlyWiki so that the performance impact of variable changes would be less but I wouldn't expect to see that anytime too soon.)

Anyway, I developed a filter operator called addposition which makes this possible (though less convenient than the feature requested here). It works by gluing the index onto the list variable. Find it here: https://groups.google.com/forum/#!topic/tiddlywiki/13_TTJqEEiw

[Jermolene]

Hi @AnthonyMuscio @EvanBalster this has come up before -- see #1523 for a proposal and #1328 for the context.

[AnthonyMuscio]

Evan and Jeremy,

Is it wrong (ignorant) then given variables forces content to be re-rendered to suggest a new class of variables be made available that do not force content to be re-rendered?

Or perhaps a way of making a section that can wrap wiki text that is not re-rendered (except the first time) unless one clicks the refresh button that appears next to it. Perhaps design to flag when it could be refreshed.

We already have the ability to wrap wiki text with monospaced block or code.

Regards Tony

[AnthonyMuscio]

Jeremy,

Was the <<iterator>> not an accepted change?, or did it fall apart later? Even a plugin?

http://tobibeer.github.io/tw/demo/#Iterator

It looks like what I suggested almost exactly. with the added advantages of odd/even and last

This would allow the post list processing to be done inside the list widget as well by doing a reveal when last is true, allowing a list to run as well as produce its final count. I can even see setting a "page break" on a count of 50 and 100 etc...

And perhaps one day we could perform an action on each list item including with the <<iterator>> and the list as a whole at the end (if not already). This would take list closer to the old TWC ForEachTiddler.

Regards Tony

[AnthonyMuscio]

Evan,

Clearly the addposition can address the requirement. Good work.

Should we still seek the original solution or make do with this "add on".

Regards Tony

[AnthonyMuscio]

An alternative to the ability to extract an index inside a list as with Tobiase's iterator and Evans addposition filter operator is to is to use the range operator to generate a sequence of numbers. There is however a disadvantage in the current range operator.

Please See Minor but powerful improvement to the Range Operator

[Jermolene]

Hi @AnthonyMuscio I think that this ticket is a duplicate of #1523 and should be closed.

[AnthonyMuscio]

Jeremy,

I do not fully understand #1523 but it sounds right, I will defer to you. So go ahead.

Will this however be a bigger change and thus take longer to arrive?

I will post some additional requirements in the Issue you referenced. Thanks Tony

[pmario]

@AnthonyMuscio ... Can you re-evaluate the OP in the light of the list-widget counter parameter -- I think this issue can be closed

[Jermolene]

I think the OP is addressed by the counter attribute.