[Feature]: Intervals, tallies and interactive tags

[thombruce]

Feature request

Reintroduce intervals and tallies in the form of interactive tags.

I think I like the simple approach of inferring this from a sort of tag meta, formatted like this:

Interval tag

[t] for "timer".

tag[t]:1h23m

Tally tag

[i] for "increment".

tag[i]:123

---

This way, interactive tags can still be inferred when todos are exported/imported from other formats.

Code of Conduct

• I agree to follow this project's Code of Conduct

[thombruce]

[t] for the timer/interval interactive tags makes total sense to me.

I'm still not sold on [i] for "increment". Other alternatives include [c] for "counter" or "count" and [n] for "number".

tag[i]:123
tag[c]:123
tag[n]:123

It's a question of which feels right and is the most universally recognisable. [t] for timer feels right, for instance, because T is used to denote time in ISO-8601 format, because mission timers (e.g. for space launches) use T- and T+.

Right now, [n] is feeling the most correct to me.

[thombruce]

If the meta is present, interactive icons should be shown next to the tag inline in the todo text.

If done incorrectly, this disrupts the editability of text, but I think if added as pseudo-content to the CSS :before and/or :after tags, we should be able to get away with it.

The actual number part will remain editable, so that values can be manually adjusted.

[thombruce]

Have been wondering for a while about storing tags in a separate attribute (a bit like how tokens are presently extracted for indexing).

So, todos might have projects, contexts, hashtags, tags and priority attributes, where (as well as being part of the editable text) they are stored separately for indexing and search purposes.

tags would be further distinct in that it would be an array of key:value pairs, which is why I mention this here. Might each tag have attributes like key, value and type, where type were indicative of the interactive types.

And if they were to have a type attribute, might they also store a non-presentation value as well as a presentation one? For example in the case of timers, should we count seconds even if the presentation version only counts hours and minutes?

We already store more precise DateTime values than we show and than will be exported (when we get around to this).

So how much does it make sense to store timers to, say, the millisecond?

---

Furthermore... and more importantly... this is really a question about maintaining accuracy when the tab is closed or out of focus.

For intervals, it is best to store the time the interval was started. This way we can present an accurate time value regardless of lost focus.

The old-style intervals store individual interval parts which would have allowed for accurate timekeeping and reviewing of the history spent on a particular task. This is obviously far more than could be added to a todo.txt line, but we could still store that information.

I would consider that more of an advanced feature best... not avoided totally, but maybe confined to a plugin. It could quickly blow up into a lot of information.

It also interferes with the editability of timers inline, requiring that we find the difference between stored and dirty values before insertion so that we can accurately represent the new increment... which is a pretty complex order.

Keep it simple: ONE value, maybe stored separately as a millisecond count, as this would allow for sortability in the future.

[thombruce]

It needn't be milliseconds. Milliseconds is just sort of the default when thinking about JavaScript time increments.

However, given that whatever it is ought to be consistent for comparison and sorting... milliseconds is probably the way to go. We may never need milliseconds, but that doesn't mean someone won't try and use Toodles as like a stopwatch for race times or something.

[thombruce]

Given which, understand that users may ultimately be able to configure their timers on the Settings page, having options between formats like:

1h23m
1h23m45s
1h23m45.000s

The only rule really is that whatever the format, it cannot feature the colon : character, hence the use of h,m,s above.

[thombruce]

At time of this comment, tags still need to be indexed properly and I believe this job should be kicked to here. We'll have a better idea of what to index then.

See: #100 (comment)

[thombruce]

Also be aware of: #100 (comment)

[thombruce]

As per further discussion on #100, the intention might be to create a new Tag class. Reasoning is on that PR, but in essence we were unable to create a useful index on the Todo objects. Because custom tags are multi-part (presently 2 separated by a :, soon to be 3 indicated by [a]), there's just no reasonable way to maintain key-value association while sorting their respective parts.

[thombruce]

Question is; do we want a separate issue to handle Tag class and indexing as-is ahead of the introduction of the interactive indicator?

[thombruce]

One difficulty with the Tag class will be this:

We need to react to tags being edited or removed from the description on Todo.

Adding them is fine. We just parse and separate as standard, but we have no way of associating a tag in a Todo description to its Tag instance. If it's edited or removed from the description, we need to react to this by checking all Tags associated to a Todo and seeing if they're still represented in the description - if not, they get scrapped. Then we can recreate from the description.

That's a simple approach, and it maintains shallow interactivity. But if we were to introduce deep interactivity (i.e. timer tags are comprised of numerous intervals for accurate time-tracking), then we would need a way to maintain tags even when they're edited.

I suggest we don't worry about that or about deep interactivity at this time. Tags should be replaced if edited. This is a good enough approach. And deep interactivity can always be maintained provided the user DOES NOT edit tags once they are in use. Ideally then, we would warn them about changing interactive tags once they are created. Maybe a "You are trying to edit an interactive tag? Are you sure you want to do this?" kind of validation warning.

But the value of interactive tags DOES change by design. To maintain this, we also need to enforce non-duplicate keys.

I'm happy with that, as I believe we should be enforcing non-duplicate keys in any case. It doesn't make sense to have pri: or due: twice on the same todo, and this in fact breaks basic interactions in other Todo.txt clients. More than happy to enforce key non-duplication at a per-todo level.

Format is this:

key[type]:value

...where type is an alpha character (perhaps preceded by a ! indicating non-use) and key and value are both any length of non-whitespace characters (except :).

We might enforce more rules than this to avoid complexity, like they should be word characters, not just non-whitespace ones. But we'll see. I'm happy leaving things fairly implicit for now, and we can see what issues arise.

[thombruce]

Tallies and intervals are now implemented as:

count:12
time:1h23m

Toodles handles these and provides interactive buttons for increasing the count or starting/stopping the timer.

We have also implemented the every: tag which enables todo recurrence.

I can't think of any other interactive features a todo item may want right now... so this can be closed. The features discussed above are no "officially" supported in some capacity.