Option to "De-Virtualize" task queries

[finn-matti]

At the moment using obsidian tasks means anti-future proofing your markdown files, because this:

due after 2021-04-04
path includes GitHub

is not readable in any other app, but Obsidian. Possibly crucial (or at least interesting) information gets lost in this way.
I therefore propose to de-virtualize these kinds of filters. Instead of writing the filter query into markdown, it should be possible to write the results directly into the file.

I could see this be done on a one-off basis (with the option to do it in bulk for export purposes):

```tasks
due after 2021-04-04
path includes GitHub
write: true
```

This would replace the text above with the results.

• task1
• task Review 🔁 every day ⏳ 2022-02-28

Or as a continuously updating process:

```tasks
due after 2021-04-04
path includes GitHub
```

• task1
• task Review 🔁 every day ⏳ 2022-02-28

Here I envision that the results are just appended under the filter itself.

This would dramatically increase interoperability and help the user that tries to keep their files future proof.

Thanks for your consideration.

[therden]

Hi @finn-matti.

I'm not Tasks' developer, just another user.

Are you aware that you can currently select and copy some or all of the results of a Tasks query and paste them into the same or another Obsidian note -- or, indeed, wherever else you might wish to have access to a static, point-in-time snapshot?

[therden]

Hello again @finn-matti.

As I said, I'm not a developer, so I can't say whether implementing your idea is or isn't feasible.

I do know that Tasks' author has had little time during the past couple of months to work on the plugin that he has freely shared with the Obsidian community -- so if you don't receive the explanation that you've requested, I hope that you'll be similarly generous with your patience and understanding.

[finn-matti]

I understand and appreciate your input and will be patient as regards to my feature requests, of course.

[aubreyz]

I don't understand the question. The whole point of a query like tasks or dataview is that it is virtual based on the actual content of files.
If you want to create a static, non-updating text file, then you can copy and paste it as above.

It is not any different to (say) embedding part of another page, or embedding an iframe or youtube video from the web. Something which explicitly imports external content (as it exists at that point in time) is not "anti future proofing" - if you want the explicitly imported content to be static, then you would make it static (which is easy to do).

[finn-matti]

I think a distinction can be made here, even though I generally agree with your point (transclusions, embeds, etc. are similar to the way queries work atm). Any of these features mean that what you see in the Obsidian client is not necessarily reflected in the notes on your file system. That is fine. It is a decision one can make and one can make that decision about any of these features separately (for example: youtube embeds yes, but no data views). Again: This is fine, it's a decision one can make.

BUT: I think task queries needn't to be virtual only. In comparison to e.g. a youtube embed, we deal with a lot less data and everything is already data that exists inside the vault. Therefore I think that it would be nice that if Obsidian stopped working tomorrow, that the latest state would be persisted inside the notes AND gets updated, just as it would, when watching the file in the Obsidian client.

So in short: Virtual displays of any kind are more dependent on the Client through which you watch your markdown files, hence they are not as future-proof as persisting the actual data in the markdown files. I think for tasks specifically it might be feasible to persist the query data in the files (optionally).

[chrsdk]

I was looking for a way to make my tasks in my daily notes static, only to stumble on this thread and sadly find out that it's not possible.

I agree with OP that it would be a valuable functionality to have.

E.g. say I have a list of overdue tasks and I complete one today. Then, when I navigate to yesterday's daily note, the overdue item no longer shows. However, yesterday the item was overdue and uncompleted. The fact that it disappeared from the list then gives the wrong information for that day.

I would be happy with a workaround, as proposed by @therden , but copy/paste doesn't seem to work. I can't select the '- [ ]' part from the output of my task query, so I would have to add that manually to each task.

I understand that it's considered (very) low priority, so I will temper my expectations.

[schemar]

Thank you for your input @finn-matti! I think you have a good point regarding compatibility/transferability. I think this would be a cool feature. However, it is low priority compared to other things that are pressing, like live preview support. I don't think I would be able to add this any time soon.

If anyone wants to jump in and code this, that could be an option to get this feature added.

[claremacrae]

See also #1216

[craigeley]

Just chiming in to say I LOVE this idea. I think the use case @finn-matti describes is perfect: making the daily note especially a static doc could really help for future-proofing and keeping a permanent record of things. Will wait very patiently to see if this ever moves up in the queue!

[therden]

Hello @craigeley.

It is easy to make the results of a Tasks query static:

In Preview mode, select and copy some or all of the results of the Tasks query, then switch to Edit mode and paste the material from the clipboard. This will recreate the query results as a list rather than a checklist -- which is good, as you'd otherwise be duplicating the todo items that the were found and displayed by the query.

(If you want the static as-of-this-point-in-time query results to replace the ever-current Tasks query, then just paste over the Tasks' query block in you Daily Note.)

If that doesn't satisfy your use-case, could you perhaps explain why? (I confess that I didn't understand either how @finn-matti's proposal for a self-overwriting Tasks query would work -- since it would automatically trigger the first time the note was opened in Preview or Live Preview mode -- or how it would be superior to the above copy-paste approach.)

[finn-matti]

The use case is future-proofing and making it easier to do so.

At the moment it works like this: Any time you open a file with a query, you see updated results. And I think this is maybe where the confusion comes from? I'll try to explain again:

The easiest case is the one-off one:

```tasks
due after 2021-04-04
path includes GitHub
write: true
```

The idea here is that this whole block would be replaced with the results of the filter. This might have to be triggered manually, maybe on save as with Obsidian Linter or through a command in the palette.

The other case of continuously updating the written result, could work very similarly, with the one crucial difference that instead of replacing the filter itself it would write out the result under the filter. Maybe a syntax like this could work:

```tasks
due after 2021-04-04
path includes GitHub
write: update
```

Why is that better than copy and pasting? I'd say it safes work, is easier to automate and overall a nicer experience for the user, without the need to switch editor modes, selecting results (which can be fiddly), etc. If you have an error in your filter: No worries! Cmd/Ctrl+Z is your friend. Adjust what needs to be changed and trigger the write again.

[claremacrae]

Thank you for your input @finn-matti! I think you have a good point regarding compatibility/transferability. I think this would be a cool feature. However, it is low priority compared to other things that are pressing, like live preview support. I don't think I would be able to add this any time soon.

If anyone wants to jump in and code this, that could be an option to get this feature added.

Just to echo what schemar said previously, if anyone wanted to implement it, I would be willing to help them get started.

However, it remains low priority compare to a large number of other requests relating to the core of the current functionality.