[IDEA] Present total items count in the list widget. We have it internally anyway.

[AnthonyMuscio]

Is your feature request related to a problem? Please describe. I often find myself using a count[] operator at the end of a filter to get the total number of items in a list. I then use the same filter without the count[] as the filter to a list widget. using the counter=item I can get the item number for each in the list.

• I can then find the last item when <<item>> equals <<items>>

However the documentation says;

Two additional variables are also set to indicate the first and last items in the list: <counter-variable-name>-first is set to yes for the first entry in the list, no for the others <counter-variable-name>-last is set to yes for the last entry in the list, no for the others

So clearly inside the list widget the total items is available internally to make this feature work.

Describe the solution you'd like Provide an additional variable that makes the total items count available inside the list widget OR Provide an additional parameter on the list widget, which resembles counter=varname, such as total-count=varname

Describe alternatives you've considered If we want to display the total items all the alternatives, involve a second use of the filter, filters with a lot of items can take time.

Additional context If we need to use a separate variable and filter to evaluate the total count, the code gets a little more complex but is even more so if we are interested in total-counts from multiple nested list widgets.

This would make use of a value presumably already known to the list widget "total items" and a code pattern we are already familiar with using the counter=countervariablkename

With the total items available, if we were also to sum a value from tiddler in the list, we could also calculate an average (without another iteration of the same filter)

How we may do it currently

<$let total-count={{{ [tag[TableOfContents]count[]] }}}>
<$list filter="[tag[TableOfContents]]" counter="counter">
<<counter>>. <$link/><br>
   <$list filter="[<counter-last>match[yes]]">
      Last of <<total-count>> divide a sum of something by total count for average
    </$list> 
</$list> 
</$let>

This is how the above could read instead;

<$list filter="[tag[TableOfContents]]" counter="item" total-count="items">
<<item>>. <$link/><br>
   <$list filter="[<item>match<items>]">
      End of <<items>> items, divide a sum of something by <<items>> for average
    </$list> 
</$list> 
</$let>

[rmunn]

There would be an interaction between this and the limit attribute. Currently even if limit is present, the list widget calculates the entire list anyway even if it's only going to show, say, the first 3 items. But I have some work planned in https://github.com/Jermolene/TiddlyWiki5/issues/7811 that would allow the list widget to be "lazy" and stop calculating list items once the limit is reached. In order for that to be possible, we'd need to define the interaction between total-count and limit to say "If limit is present, total-count will never be greater than limit, though of course it might be less." I.e. if you have five tiddlers tagged with Todo and you do <$list filter="[tag[Todo]]" limit=3 total-count="items"> then the value of items would become 3, not 5.

I believe this is what you would want anyway: in any scneario I've come up so far, you would want to know how many list items the list is actually going to display, not how many it potentially could have displayed. But it's definitely worth clarifying that iteraction now, before anyone actually encounters it in practice.

[AnthonyMuscio]

I do not have knowledge of the javascript but the existing feature "<counter-variable-name>-last is set to yes for the last entry in the list, no for the others" is theoretically already taking this into account.

[saqimtiaz]

There are performance considerations to the proposal. See https://github.com/Jermolene/TiddlyWiki5/pull/5867 for a prior discussion that includes implementation ideas.

[AnthonyMuscio]

@saqimtiaz I( need to leave performance considerations to others, but I would have thought the logic needed to provide the <counter-variable-name>-last would already have impacted the performance and making the total items only a matter of returning it.

• To not have this feature, the same filter needs to be run with a count operator to get the total which seems a more costly way

[saqimtiaz]

@AnthonyMuscio the reason for the performance impact is discussed in the linked issue.

[AnthonyMuscio]

@AnthonyMuscio the reason for the performance impact is discussed in the linked issue.

As I said, I looked and cant understand or provide any input.

[AnthonyMuscio]

I note that the existing count widget, and count operator may already have code in relation to the total items after the limit[] operator. thus may be related to any resulting fix.

[AnthonyMuscio]

I believe what I proposed is correct and I don't understand the arguments at the link I was directed to.

I have since stored the total count in behind a custom widget for list reports.