Recurring Tasks
Eduard Metzger
Create recurring tasks with links like
>d
for every day, etc: [+][0-9][dwmqy]
.- Completing a recurring task, a copy is added to the note (hide link)
- Define intervals like >2w-sun= every second week on a Sunday
- Define timeframes like >week42= link to every day of defined week
- With start date >2022-03-26-2w-sat(if it should appear only on this date and beyond)
Use case examples:
- I would like to send an email to my scrum teams every two weeks on Thursday.
- I want to do maintenance on the boat every 2 years in January
- I want to review and update the released tasks in Jira every 6 months
Eduard Metzger
Eduard Metzger
This is currently a limitation of the current implementation, but there is a new implementation planned where this becomes redundant (means it works without end-date). Will merge it with the other request.
Anton Sklyar
Eduard Metzger : I like how recurring tasks are implemented in Things (when you have a “basic” recurring task that describes the rules and “next occurence” task copy that is created from that “basic” task as soon as the previous occurence has been completed), and from what I understand, the mental model of the feature you suggest is similar (create a copy when previous task has been completed).
But I think this will be counter-intuitive in the terms of NotePlan todo syntax.
- First of all, “>” is for scheduling of a concrete task on a concrete day, and here you break that semantics.
- It’s unclear how re-scheduling would work in case of recurring task.
- If you create copies of the task for each recurring day, you cannot properly backlink the copy to the original recurring task instance.
Maybe a better scenario would be just adding an option to
copy selected task to provided days
. So instead of re-scheduling I could provide the date range and task repeating rules, and NotePlan would copy the task to all of the daily notes that correspond to the provided repeating rules. Thus, they will remain “good old simple daily note tasks” without any syntax breaking or overcomplicating things, but solve the purpose of recurring tasks.Moving a little bit further, if I am cloning a task that way and NotePlan detects that there is exactly the same task in any of the future daily notes (which probably means that I’ve already made that task recurring using the technique described above), NotePlan could ask me if I want to clear those copies before creating new clones on a new schedule.
Anton Sklyar
Funny thing: right after writing this post yesterday, today I discovered that this is already (partly) implemented in NotePlan :D
Truly, sometimes we ask for the features that we already have, just because we do not discover them in proper time ))
Point of improvement would be the ability to repeat every X days, every weekday, and something like "every 1st Saturday of the month".
Rhubarb
Anton Sklyar: Some features related to scheduling would be much easier to discover, if the menu items where called "schedule". Who expects a command called "Mark as moved" to open up a date picker with a "repeat" sheet?
This usability issue would be really easy to fix. I wrote up a detailed feature request: Wording: Call schedule "schedule" again
Naman Goel
While I like this idea, I don't think adding ever more syntax inline this way is scalable. It would make sense to add this feature after implementing a plug-in API. Then, custom tags can be implemented as plugins which can be written in a language like Javascript.
Then we could write something like this:
- My recurring task #<EveryDayExceptSunday>
And the
EveryDayExceptSunday
would be a custom tag implemented by a Javascript plug-in that implements the behavior.Then a plug-in could work something like this:
import {DailyNotes, Date} from 'NotePlanPlugin';
export default {
type: 'customTag',
tag: 'EveryDayExceptSunday',
scope: ['tasks', 'subtasks'],
events: {
onCreate() { /* Do Nothing */ },
onCompleted(task) {
const today = Date.today();
let nextDay = today.addDay(1);
if (nextDay.dayOfWeek === 'Sunday') {
nextDay = nextDay.addDay(1);
}
if (task.isInDailyNotes) {
DailyNotes.on(nextDay).add(task.textValue);
} else {
task.textValue.replace(/>[\d]{4}-[\d]{2}-[\d]{2}/, nextDay.asTag);
}
}
}
}
Rhubarb
I support this idea:
- keep the default syntax plain and simple
- let plugins handle more complex behaviors (for those users, who want them)
- let plugins handle different methods to define the schedule, so that every user is free to choose whatever they prefer
- ensure compatibility with standard syntax (this might require some fine-tuning to the standard syntax)
Eduard Metzger
Naman Goel: Oh yes! The plug-in framework is already work in progress. Join us on Discord, if you want to try it out and shape how it behaves: https://discord.gg/C74kz9fz
Eduard Metzger
Rhubarb: Plug-ins would definitely work for “repeat by copy” and I got a framework in alpha with which one can build it already, but they wouldn’t support linking behavior like appearing in the references, except the plugin populates a list of date links and adds them to the task, which would make it cluttered.
Rhubarb
Eduard Metzger: I assumed that Noteplan had a one-task-one-date paradigm. A task is either done or cancelled or scheduled.
Repeat by copy should work like
@repeat(…)
does now. It should create copies of tasks, not append multiple dates to one tasks.Rob Grace
Rhubarb: agree, it would need to be "reschedule on completion", and this behavior may not be obvious to the standard user*. Whereas, a plugin's Readme could lay out the caveats.
*It would be easy for them to assume the other alternative... "repeated dynamically", as in most Calendar apps. I can't imagine how this would scale up to a database of 1000s of notes, if the syntax on every task had to be reevaluated for repeats, when navigating to a daily note ("do any repeat tasks show up on this date?"). We already see evidence of slowdown with traditional task date parsing.
Rhubarb
On a second thought, I might have an idea what Eduard Metzger could be aiming for. Some kind of automatically growing list that logs completed tasks? That would be similar to my example of Spanish classes, but with less manual work.
Let's say I wanted to practice Spanish every weekday and keep track of my progress. I'd create a note named "Spanish" with one task:
- [ ] Daily Spanish lesson >somemagicsyntax
The first time I complete the task, the note would look something like this:
- [x] Daily Spanish lesson @done(2021-03-29)
- [ ] Daily Spanish lesson >somemagicsyntax
That would be pretty useful for tasks like reminding myself of and keeping track of regular backups.
I love date tags in general notes. But… the problem is the syntax. Simple date tags are simple, because they use simple ISO dates. But what syntax would you use, that handles all the date scenarios you're interested in
and
doesn't require a Masters degree in Computer Science?And I'd like to keep date tags conceptually simple. They should refer to real dates, not to a formula. What about something like this:
- [x] Daily Spanish lesson @done(2021-03-28)
- [x] Daily Spanish lesson @done(2021-03-29)
- [ ] Daily Spanish lesson @every(somemagicsyntax)
Or are you going for something else?
Rhubarb
Or are you talking about recurring tasks in
daily
notes, Eduard Metzger? So every time a recurring task is checked in a daily note, a new copy will be created in the next daily note that matches the creation pattern?
For example, in today's note there is this task:
- [ ] Check Canny for updates >somesyntaxforbusinessdays
When I check this task, it will become:
- [x] Check Canny for updates >somesyntaxforbusinessdays
And a new task will be copied to the day note of the next business day:
- [ ] Check Canny for updates >somesyntaxforbusinessdays
This behavior would also make sense to me. Although I'd prefer a different syntax for plain date tags and automation that creates copies. Maybe something like:
- [ ] Check Canny for updates @autorepeat(somesyntaxforbusinessdays)
or
- [ ] Check Canny for updates @every(somesyntaxforbusinessdays)
The syntax should be different from simple date tags, so that it can be easily recognized as a potentially complex set-up-and-forget-automatisation.
Eduard Metzger
Rhubarb: Very similar, the link would be created either manually once you learned how, by natural language input (if I find a library which can do that) or by a dialog like in any other todo app. Instead of linking 1:1, it would link 1:n. Means from the note you created the task to multiple daily notes. Checking off the repetition could make a completed copy with a done tag and paste it into the referenced day.
Rhubarb
Do you have a use case where this behavior would be useful? I'm still not seeing the bigger picture here. Sorry for my lack of imagination. :-(
Jonathan Clark
What I've implemented which works well is
@repeat([+][0-11][bdwmqy])
. This adds the b
for working day (i.e. ignore weekends), and allows up to 11 of something.Rhubarb
Jonathan Clark: Yes, something like
@repeat(…)
would be a much better fit for such a complex behavior.Rhubarb
Woah. This mechanism is way too complicated for my brain. I'm already struggling with simple "schedule/move" and "repeat" commands.
My brain could handle an "auto-fill" command that automatically populates daily notes with copies of a task template. Similar functionality, but different mental concept.💡 An auto-fill command as separate entry in the Edit-Menu would also be a great opportunity to provide often requested templates.
Please, don't break the
>
-notation. It is already in good use for date tags like >2021-03-30
(and eventually >2021-W13
).Eduard Metzger
Rhubarb: You wouldn’t have to type it yourself, NotePlan would create the link after defining the recurrence rules in a popover similar to the current one but with more options. I don’t really like the repeat by copy feature. I think repeat by linking is better. That’s similar to the moving, scheduling and linking discussion.
Rhubarb
Eduard Metzger: I agree that is is part of the moving/scheduling/linking discussion. But I miss the bigger picture, the design concept. This might be an issue for some top-down thinking…
BTW, for me repeat by copy makes more sense than "move" by copy. ;-)
The problem with
@repeat(…)
is not the copies, but that it's so difficult to update or delete the copies, once the tiniest changes are made. Technically speaking, that could be resolved with some kind of metadata or unique ID that identifies related copies.Jonathan Clark
Eduard Metzger: Interesting that you say, "I don’t really like the repeat by copy feature. I think repeat by linking is better." I rather thought your existing
repeat(n/m)
mechanism was a copy mechanism?Anyway, I'm with Rhubarb on the current difficulty of updating/deleting those
@repeats
. IMHO the system I use is less fragile, and easier to change, as the next date only gets worked out on completion of the current task. Though now I think about it, whie that's clearly necessary for the "2 months later" (e.g. haircut) case, it perhaps doesn't suit the "5th of every month" (e.g. check bank statement) case. So, if I forget to balance the bank statement in March, or mark it as done, I'm not going to get to see the April task. Hmm.Eduard Metzger
Jonathan Clark: Yes, it's currently a copy mechanism and I don't think it's ideal. Mainly because deleting or changing is not very elegant like you mentioned due to the nature of having plain text files. It's not easy to reverse a repeat action.
Having a link has the advantage that you can change the task and it updates everywhere or delete it easily at the source.
Eduard Metzger
Rhubarb: A repeat link can solve this! See it as scheduling 1:n instead of 1:1. Changing the text in the original link, changes all "backlinks" where it occurs (in the daily notes).
Rhubarb
Eduard Metzger: I get the idea, but I don't like it.
I'm struggling with the word
link
for this feature. In my mind links
build a graph, they don't assign a date to a task.I'm afraid that you are about to break the best part of Noteplan:
interoperability
with other Markdown apps. I can access [[links]]
with Obsidian. I can search #hasthags
with iA Writer and other writers. Even your additions to GFM's checkboxes are somewhat downward compatible with other apps.I don't mind advanced type-ahead features like
>in2weeks
, that are resolved to a date, that is written out as >YYYY-MM-DD
in a regular note. I don't mind macros for date offset patterns (such as {-10d}, {+2w}, {-3m}) in jgclark's scripts, that are resolved to a date that is written out as >YYYY-MM-DD
.But writing
>week42
in a note is a different thing. Notes become scripts
that can only be interpreted by one app: Noteplan.Then there is still the unresolved design issue with the trace of procrastination in daily notes, that also uses a
>
-syntax, but with a different meaning.And why
>
for this completely new behavior? Could you at least come up with a different syntax? Personally I hope you to fix the basics first,
before
introducing new functionality, that makes an already complex design problem even more complex. The basics are: a consistent Markdown syntax and a consistent wording for existing features.Rhubarb
Jonathan Clark: I like your idea, because if you mark a repeat-after-done task as done, even if you haven't actually done it, it will appear in the next month. :-) And once it is checked off, it has no automatism attached to it, so you could delete the task, or mark the task as Cancelled as a reminder of things not done. ;-)
If you don't mark it as done, it will appear in Overdue (once the bug in Review is fixed).
Repeat-after-done
would match my brain perfectly.Eduard Metzger
Rhubarb: Yes, true, this would break with other apps. Obsidian, etc. don't have this functionality and probably will never have it, though.
However, this can be a user-choice. I don't want to limit NotePlan's feature set to what other apps allow. If someone wants to keep full compatibility with Obsidian, which doesn't have recurring tasks, then don't use it or use a macro-style recurring method using a plugin.
What I don't like about a macro (copying the task over specific notes), is that this is hard to modify or delete, since the task is in plain text files and not a database entry with an ID.
On the term "link", I know, we have a different meaning in our minds :)
Rhubarb
Eduard Metzger: Agree on the term "link". My mind can't process the meaning you seem to have in your mind. I'll continue to call bits of data that are tagged to block items "tags". I hope your mind can translate. :)
Interoperability with other apps is an issue for users who access Noteplan's file with other apps or frequently exchange data with other Markdown apps. I stopped using the
>
-notation in notes that I access with other Markdown apps, because it looks odd. (I also stopped using the task states - [-]
and - [>]
for the same reason.) For some reason I find
@YYYY-MM-DD
or @somekeyword(…)
easier to ignore in Markdown apps that don't fully support Noteplan Flavored Markdown.Eduard Metzger
Rhubarb: I got used to how you call things, no problem for me:)