This needs to be added in the same row as the // to be applied to that task.Īn example task would be something like so: Same goes for date-related values only you combine the type of date with the actual date.The entire row without the // ‘fields’ would be the description of the task. The different statuses could be realised by using the status prefixed with a “//” (other modifier keys can be used ofcourse).įor example //todo or //waiting.below) that status is then the task defining syntax. If you specify that a task always has/needs a status (see point 2.With that in mind you could use the following syntax to work with the points mentioned above. I think the assumption can be made that a task is always only on 1 row (although it can be on multiple lines in the editor). are there more things to be tracked about a task … ? Not in my use case, but please add….date related values (created, started, due, scheduled, cancelled, done, also many more possiblities).the status of task (todo, doing, now, later, waiting, cancelled, wait on client, wait on co-worker, anything you want).Things you would like to track about a tasks are:

I understand we need some kind of syntax to define a task but a list should not be needed.

Why does it need to be in a list? Feels very unnaturally when I am writing a text and add a task somewhere in the middle (on a separate row). Some point to improve on the core task options: To say it frankly and with respect to plugin developers … I think most task related plugins are not needed when the core task system would be improved on. I am a simple user of obsidian and not a plugin developer but I would like to see that the core method of working with tasks is to be improved on instead of developing a standard for so many plugins.

GoodTask instal the new