search

thombruce / toodles

✅ A super simple todo app
https://toodles.thombruce.com/
GNU General Public License v3.0
0 stars 0 forks source link

[Feature]: Repeatable todos #99

Closed thombruce closed 1 month ago

thombruce commented 1 year ago

Feature request

Some things you wanna do every day/week/month. Introduce scheduled todos that repeat based on user-defined rules.

Not sure how this is gonna work yet, but perhaps it's possible using the same system as interactive tags (#97). For instance...

scheduled[s]:weekly

A 'scheduled' todo could be denoted by the s type (or 'repeatable' by an r type) and the tag value could be used to determine the repetition interval.

IF a deleted todo has a scheduled/repeatable type tag, then it should be duplicated provided that the completed date is the "scheduled" amount of time in the past.

It would not be recreated if it were still active.

Could introduce a "schedule" format similar to timer format: 1w2d3h45m indicating that a todo should be duplicated if it were completed "1 week, 2 days, 3 hours and 45 minutes ago".

The challenge...

How do we tell the new todo apart from the completed one, such that the completed one is not recreated more than once?

We could mark the scheduled tag as stale in its metadata (#98). Or we could mark the new todo as derived from a parent and check for this. The former seems intuitively less intensive. But it still has a problem: After an import/export to another app/domain... the metadata is lost unless we note it in the todo description somehow.

Consider:

2023-07-01 Get milk every[s]:1d
x 2023-07-01 2023-06-30 Get milk every[!s]:1d

...where a ! has been used to indicate that the [s] condition is already met. Alternatively, you could just strip the type from the ancestral todo after duplication. Depends: Is [type] useful even in posterity?

2023-07-01 Get milk every[s]:1d
x 2023-07-01 2023-06-30 Get milk every:1d

Code of Conduct

thombruce commented 1 year ago

We could eventually make the decision about whether to mark [type] obsolete ([!s]) or remove it to the user. The difference between both approaches is trivial from a programming POV.

thombruce commented 1 year ago

Alternative to checking for archived todos to create new todos from at launch (which could miss todos unless we had a periodic interval running while open)...

Consider recreating the todo at completion time - it could have a meta value indicating that it should be hidden until a certain date/time.

In fact, we can use the already existing "created" date. The app would show only those todos with "created" in the past/present; future todos would be shown when their "created" is past/present too.

Problems?

Well, it does eliminate an interval script having to check for and create these duplicates on the fly... but we do still need to show these todos on the fly as they become present. This still requires an interval, albeit a less intensive one (it's just a query).

thombruce commented 1 year ago

Compare plan with ice_cube gem for Ruby/Rails: https://github.com/ice-cube-ruby/ice_cube

See also there how iCal handles a similar concept with a unique syntax.

See if there is an existing, similar solution in JavaScript.

thombruce commented 1 year ago

Best I can find yet is mention of two packages in this issue on the ice_cube Ruby gem: https://github.com/seejohnrun/ice_cube/issues/457

Check them out.

thombruce commented 1 month ago

This is now implemented in the form:

every:Week
every:Day
every:Wednesday
every:3Days
every:Monday,Wednesday,Friday
every:Fortnight

Not entirely extensive but versatile enough for now. We will add more convenience strings in the future but this can be closed now.