See the possible future recurring tasks with filters

[hasanyilmaz]

⚠️ Check request is valid.

• My request is about the Tasks plugin for Obsidian.
• I am only requesting a single feature in the Tasks plugin. Multiple changes should be split into individual requests, with links between them.
• I believe my requested feature will be generally applicable to other Tasks plugin users, not just me: it is not uniquely tied to my personal workflow.

⚠️ Please check that this feature request hasn't been suggested before.

• I searched previous Tasks plugin Ideas in Discussions didn't find any similar feature requests.
• I searched previous Tasks plugin Issues didn't find any similar feature requests.

🔖 Feature description

Sometimes I am checking this/next month or all tasks. Is it possible that may I see all future recurring tasks with filters? I wanna see that day's time availability.
That can be a filter element with date range or work with other limitations in filter.

✔️ Solution

That kind of function helps to see the future day's time availability and better time management.

❓ Alternatives

No response

📝 Additional Context

No response

[claremacrae]

Hi, thanks for writing up the suggestion.

Question 1

Is it that you want Tasks query/search results to be able to include future instances of recurring tasks - future instances that have not yet been created?

[hasanyilmaz]

Hello,
yeap, and thats the critical part probably. yes, I wanna see future instances which are not created yet.

[claremacrae]

Question 2

OK, so let's suppose that this feature is going to be implemented - please help me work out what the expected behaviour should be - to make sure it's not confusing for plugin users, plugin developers or both!

Sample Markdown

Suppose that we have this task:

- [ ] Do on the first of every month 🔁 every month ⏳ 2025-08-01

The new search results

And suppose this requested feature exists.

Then you have a query that somehow shows these results, even though there is only the first task that actually exists in Markdown:

- [ ] Do on the first of every month 🔁 every month ⏳ 2025-08-01
- [ ] Do on the first of every month 🔁 every month ⏳ 2025-09-01
- [ ] Do on the first of every month 🔁 every month ⏳ 2025-10-01
- [ ] Do on the first of every month 🔁 every month ⏳ 2025-11-01
4 tasks

How should the results appear and behave?

What will the 2nd, 3rd or 4th tasks in the results look like?

• Are they identical to the 1st (existing) one?
• Are they different in some way - how?

What do you think should happen if the user interacts with the 2nd, 3rd or 4th task?

• What should happen if they toggle a non-existing task?
  • The current behaviour is that toggling a recurring task completes the current instance, and creates a new one.
  • But here, there is no current instance, and if a new one is created, it will eventually become a duplicate as earlier (real) instances are completed.
• What should happen if they edit a non-existing task?
• Or should they even be allowed to edit them at all?

[hasanyilmaz]

Instances in filters

---

Ok, lets start. Firstly as a user, I need a keyword in filter; For now name it like "instance". (Name of that keyword just an example)

If I had with that "instance" keyword, I can see all the tasks with an instance number. It shows up only with that keyword in filters.

The created task is our reference point. So that task is the first instance. Also we can use vertical recurring icon for instances.

🔄 : recurring tasks' frequency
🔃 : recurring tasks' instance number

In that case, I will see the recurring tasks with their instance numbers like that (with keyword or only number):

- [ ] Do on the first of every month 🔁 every month 🔃 instance 1 ⏳ 2025-08-01
- [ ] Do on the first of every month 🔁 every month 🔃 instance 2 ⏳ 2025-09-01
- [ ] Do on the first of every month 🔁 every month 🔃 instance 3 ⏳ 2025-10-01
- [ ] Do on the first of every month 🔁 every month 🔃 instance 4 ⏳ 2025-11-01

Note: That kind of filter has no end. So there should be a way to stop the recurring task instances. Like a core limit min-max 100-1000 and adjustable in filters. Not sure about performance issues.

Non-created instances' line can be lighter than normal tasks. Like %80 boldness?

How can we deal with instances?

---

2nd, 3rd or 4th instances can not be completed by the user. May be an error message or a warning "Only 1st instance can be completed.". I dont know thats possible or not.

Toggle circle normally clickable. But for instances (2nd and more) it’s not clickable and some kind of icon in circle. ?

Non-editable part for instances ended.

---

Real deal with instances is in "Create or Edit Task" window.

Option 1: A new window just for instances.
Option 2: Or an extended version of the current window if we are dealing with instances. If we are dealing with normal tasks, we can have same normal window.
Option 3: Your idea?

Till here, what do you think? I will add my opinions after your thoughts.

[claremacrae]

Separate tickets for separate requests

Ok, lets start. Firstly as a user, I need a keyword in filter; For now name it like "instance". (Name of that keyword just an example)

No, A new field, with new emoji, is very definitely a different feature from the rendering of not-yet-created task lines.

It's just not feasible to manage independent features in the same ticket - it's very demotivating to complete one aspect, and not being able to mark the ticket done.

It's also hard enough keeping track of all the discussion on one topic.

There are probably already requests for an instance or counter on task lines - but if not, you are welcome to create a separate feature request, explaining why the feature is essential.

[claremacrae]

Question 2 - answers

What will the 2nd, 3rd or 4th tasks in the results look like?

• Are they identical to the 1st (existing) one?
• Are they different in some way - how?

So, it sounds like the display should somehow indicate that the not-yet-created recurring tasks should be displayed differently in some way.

You suggested:

Non-created instances' line can be lighter than normal tasks. Like %80 boldness?

What do you think should happen if the user interacts with the 2nd, 3rd or 4th task?

• What should happen if they toggle a non-existing task?

  • The current behaviour is that toggling a recurring task completes the current instance, and creates a new one.
  • But here, there is no current instance, and if a new one is created, it will eventually become a duplicate as earlier (real) instances are completed.

• What should happen if they edit a non-existing task?

• Or should they even be allowed to edit them at all?

Conclusion: It should not be possible to make any edits to these not-yet-created tasks.

Only the currently-existence instance can be edited.

This means:

• no Pencil icon on search results (or it is present but disabled, and hovering over it says "cannot edit a future task recurrence" or similar
• No right-click context menus - or again, they show a message explaining why they are inactive.

[claremacrae]

Question 3 - how to enable the feature?

1. How will the Tasks plugin know, for any given search, whether to include future instances or not?

2. How will the Tasks plugin know, for any given search, how far ahead to create future instances?

You suggested above:

Note: That kind of filter has no end. So there should be a way to stop the recurring task instances. Like a core limit min-max 100-1000 and adjustable in filters. Not sure about performance issues.

Yes, I was wondering about performance issues.

I had been thinking about going forward a certain distance in time, like "create tasks for the next 3 months", as a fixed number like '100-1000' doesn't seem right for yearly tasks.

(If the search was for tasks in a certain date range, it might seem logical to create future instances of tasks until the end of the date range. But that would only be feasible for the most trivial of queries - as soon as Boolean combinations or filter by function gets involved, it's not going to be feasible to work out the date range automatically, so I was thinking the user will need to specify it)

I am presuming that there would be new Tasks query instructions, but nothing obvious springs to mind as to what to call them.

Suggestions and ideas, please...

[hasanyilmaz]

Ok, lets return to the main topic. :) I answered the questions with an editable mindset at the end. But thats not my main point. I just wanna see only future instances with that request.

So, new emoji and new keyword for instances part is for editable part preperation. Thats not necessary. I understand that instances are not editable. No problem.

Instances can be lighter than normal tasks like %80 boldness. I dont understand it is possible or not.

No pencil, no right click, no edit, no creation icon and hovering message seems good. Also a custom status icon can be dedicated for all instances?. That shows these tasks can not be editable better. Like that (with calendar icon but not editable):

- [ ] Do on the first of every month 🔁 every month ⏳ 2025-08-01
- [<] Do on the first of every month 🔁 every month ⏳ 2025-09-01
- [<] Do on the first of every month 🔁 every month ⏳ 2025-10-01
- [<] Do on the first of every month 🔁 every month ⏳ 2025-11-01

As a user, I wanna see future instances with a date range. On the other side, I think instance number is more important than date range for performance. Its a computing issue. That can be a soft intersection.

In Tasks plugin possible general settings:
Show future instances, on/off
Date range
Instance limit per query
(both date range and instance number can be there i think.)

If user dont want to see future instances in only one query, they can turn it off by in filter?. (instances on/off)

[claremacrae]

Thanks @hasanyilmaz - very help.

Question 4 - last question

How do you think this should work with task lines like:

- [ ] Do something most weeks - but is currently overdue 🔁 every 7 days when done ➕ 2025-07-07 ⏳ 2026-07-01

This is an overdue task, but when it is completed, because of the when done the new due date will be calculated based on the date that it was completed.

The only thing I can think of is to calculate future tasks based on the assumption that the task will be completed today, and then always not the next due date.

But that is likely not at all realistic.

[hasanyilmaz]

In that case you used scheduled date. I see that it behaves differently than due date. First time I see that. Normally I dont use only scheduled dates.

- [ ] Do something most weeks - but is currently overdue 🔁 every 3 days ➕ 2025-07-08 📅 2025-07-15
- [x] Do something most weeks - but is currently overdue 🔁 every 3 days ➕ 2025-07-08 📅 2025-07-12 ✅ 2025-07-08
- [x] Do something most weeks - but is currently overdue 🔁 every 3 days ➕ 2025-07-08 📅 2025-07-09 ✅ 2025-07-08
- [x] Do something most weeks - but is currently overdue 🔁 every 3 days ➕ 2025-07-08 📅 2025-07-06 ✅ 2025-07-08
- [x] Do something most weeks - but is currently overdue 🔁 every 3 days ➕ 2025-07-01 📅 2025-07-03 ✅ 2025-07-08

- [ ] Do something most weeks - but is currently overdue 🔁 every 3 days when done ➕ 2025-07-08 ⏳ 2025-07-11
- [x] Do something most weeks - but is currently overdue 🔁 every 3 days when done ➕ 2025-07-08 ⏳ 2025-07-11 ✅ 2025-07-08
- [x] Do something most weeks - but is currently overdue 🔁 every 3 days when done ➕ 2025-07-07 ⏳ 2026-07-01 ✅ 2025-07-08

I use due dates always for recurring tasks. So with due dates, it can create past day tasks.
So which approach is correct in here? due dates or scheduled dates.
I think due dates are correct.

Do you use scheduled date because of Day Planner?

[hasanyilmaz]

There can be a dedicated file(s) for only task instances. Some plugins use a specific file for tasks. I don't know the coding side, but that can be by-pass calculation heaviness for every query. Non-editable file for users.

Short scenario:
I create a task with weekly recurring.
New future instances created immediately in "instance.md". With current rule set with due or scheduled date.
That future instances should be stopped with our Time and Count Limits.
That instance limit can be also ruled for just one task? For example 100. (daily instances will be heavy.)
After I complete my reference task, the next future instance will be deleted from instance.md and created in our completed task's file and place.

There can be only one instance.md or many files for every recurring task.