Tiddlywiki5: Filter operator rest always drops at least one item

Created on 19 Jun 2017  路  7Comments  路  Source: Jermolene/TiddlyWiki5

According to the documentation, if no parameter for rest is supplied, it defaults to 1. However, if 0 is supplied as a parameter it is also interepreted as 1 due to the following code:
var count = parseInt(operator.operand) || 1,

This means that a filter like [tag[note]rest<x>] will always drop the first item when x is 0 and return the same results when x is 1. Is this the desired behaviour? If so the documentation needs to be updated.

It would be desirable for the filter to not drop any items when the parameter is specified as 0, as this allows for using a filter like [tag[note]rest<x>] where x is an incrementing variable, for the purpose of pagination. As it is now, this is not feasible as when x is 0, the first list item will be dropped.

Most helpful comment

Defaulting to 1 does not at all mean the same as interpreting 0 as 1. A default value is applied when no value is given. So based on the documentation, I would expect rest[] to behave like rest[1] which it does. But I would not expect rest[0] to behave as rest[1].

If this is indeed an intended behavior and the core relies on it, then sure lets update the documentation to make this clear. @Jermolene ?

If this is by accident, then I think it is worth considering in a bit more detail. I think it would be an extreme edge case that someone is relying on rest[0] behaving as rest[1], minimizing backwards compatibility concerns.

All 7 comments

I think, this behavior is intended. So we need to update the docs.

IMO it's not possible to change the behavior anymore. It would cause a backwards compatibility problem.

http://tiddlywiki.com/#rest%20Operator points out, that parameter defaults to 1

IMO the listops filters may do what you need: http://tiddlywiki.com/#ActionListopsWidget

Defaulting to 1 does not at all mean the same as interpreting 0 as 1. A default value is applied when no value is given. So based on the documentation, I would expect rest[] to behave like rest[1] which it does. But I would not expect rest[0] to behave as rest[1].

If this is indeed an intended behavior and the core relies on it, then sure lets update the documentation to make this clear. @Jermolene ?

If this is by accident, then I think it is worth considering in a bit more detail. I think it would be an extreme edge case that someone is relying on rest[0] behaving as rest[1], minimizing backwards compatibility concerns.

But I would not expect rest[0] to behave as rest[1].

OK. I can see your point.

@pmario I've looked at the list-ops filters and their usability for this situation is greatly hampered when not dealing with a list that will persist in a field. But thanks for the suggestion. It is a bit unfortunate that something rather commonplace like pagination is difficult to do with just whats in the core, but I'll save those thoughts for a discussion thread or a separate ticket so as to not go offtopic here.

@saqimtiaz: I would also be in favor of fixing. If you explicitly ask for 0, nothing should be returned, instead of 1.

My suggestion: make a PR with the change and close this.

Was this page helpful?
0 / 5 - 0 ratings