More options for handling "Done" instances of recurring tasks

[therden]

When a recurring task is completed, Obsidian Tasks' currently adds a "Done" signifier and the current date to the completed task, then inserts a new line containing the next instance of the task above it in the same markdown file.

But I have many recurring tasks that I don't want to retain once they're completed; and I frequently would prefer that the completed instances that I are retained weren't cluttering up the file in which they originated. Consequently, I suggest that this plugin support two more options for handling completed instances of recurring items:

1. Appending the completed instance of the task (with its Done date) to a user-configurable log file of completed recurring tasks and saving the next instance of the task in place of the completed instance in the originating file; and

2. Overwriting the completed instance in the original file with its next instance without saving the completed instance anywhere.

This enhanced flexibility could be supported with a new Setting named something like "Save completed recurring items", with the choices:

• "InPlace" (the current behavior)
• "ToLogFile"
• "NoSave"

But it would be great if, in addition to a vault-wide behavior, it were also possible to specify the desired behavior for each recurring task.

[schemar]

Thank you, @therden! I don't think I would put in the effort to allow for log files, which would need to be configurable.

Question: how would you handle different behavior on a "per task" basis? How would you tell tasks how to handle each task?

[therden]

I was thinking that per task over-ride of the default handling of completed instances of recurring tasks could be triggered by a new signifier, followed by whichever supported option is desired: [signifier] inplace, or [signifier] tologfile, or [signifier] nosave.

[therden]

@schemar wrote:

I don't think I would put in the effort to allow for log files, which would need to be configurable.

Just in case it would meaningfully reduce the implementation effort required: even if the location and name of the file where the completed instances of recurring items were saved were not configurable, I'd still consider having the option to save them outside of the originating file a big win.

[caasion]

I was thinking that per task over-ride of the default handling of completed instances of recurring tasks could be triggered by a new signifier, followed by whichever supported option is desired: [signifier] inplace, or [signifier] tologfile, or [signifier] nosave.

This could also be put before or after the recurring instruction, but it would be separated by a character that isn't used in the recurrance.

[pcause]

in the packer plugin they add a %%done_del%%to the task to indicate it should be deleted. the plugin has to be run manually but it will delete all items marked done that are recurring. Using a similar scheme could work