Reformatting and rearranging Tasks source code - Tuesday 6th September 2022

[claremacrae]

tl;dr

If you have any PRs in-flight, please try to submit them in time for being reviewed and merged by Tuesday 6th September 2022, before a reformatting and restructuring exercise will start.

Motivation

Over time, Tasks and Tasks SQL Powered have both been evolving and improving.

I would like to make it easier for:

• Improvements in Tasks to be merged to Tasks SQL Powered
• And for some of the improvements in Tasks SQL Powered to be merged back to Tasks

To this end, I sometimes compare the two projects in a diff tool, and this is harder than I would like it be because the two projects differ in:

• Directory structure
• Formatting (line length)

Small differences in directory structure
Tasks on left. Tasks SQL Powered on right
Events.ts, Query.ts and Sort.ts on the left have all been moved and/or renamed on the right

Differences in line length, in snippet from tests
Tasks on left. Tasks SQL Powered on right

Proposal

Starting Tuesday 6th September 2022, I would like to:

• Increase the line length in Tasks to match that in Tasks SQL Powered - which from memory is 100.
• Review differences in directory structure and file names between the two projects, and rearrange Tasks to match the current state of Tasks SQL Powered

[claremacrae]

OK It turns out that Tasks SQL Powered uses a line length of 120.

What I'll do is try reformatting at that length first. If it feels comfortable to me, on a widescreen and a laptop, and looks moderately readable when printed, I'll stick with that.

If not, I'll fall back to 100 and use that. It will still significantly reduce the number of diffs between the two code bases anyway.

[esm7]

I'm all for a longer line length 😎
But for the purpose of a broader discussion, can you share what is the goal of getting closer to Tasks SQL Powered?
Is SQL a direction you want Tasks to go in as a query language? Or are there other changes in Tasks SQL Powered, which seem to not be listed in the Readme, that Tasks would rather adapt?
At least by the way it seems to me, the core functionality of Tasks SQL Powered may not be so needed anymore by most users now that we have full boolean operators. And for other extremely power users that may want even more control over task queries, if there's a meaningful number of these, maybe it's worth a separate discussion about how to address their needs (I personally have ideas that I think are preferable over SQL, again, given the current new query abilities of Tasks).

[claremacrae]

Hi @esm7 Just wanted to make sure you've seen the replies above... Any comments welcomed...

[esm7]

Oh sorry, I'm back from my long vacation and am so incredibly behind in so many places!
I think that as always, you elaborated very clearly what the considerations are. I'm not sure I would do the same thing if I was in your shoes, since it seems like a lot of weight is given to a small fork that doesn't add much functionality that you actually want to use. But I also see the benefits you are pointing out, and will definitely enjoy the longer line length :)

[esm7]

And for other extremely power users that may want even more control over task queries, if there's a meaningful number of these, maybe it's worth a separate discussion about how to address their needs (I personally have ideas that I think are preferable over SQL, again, given the current new query abilities of Tasks).

Please feel free to start a separate discussion about that. It sounds very interesting!

Just noting here (also for myself, since I will surely forget in a few months what I meant ;-) ), that if there is a true need for considerably more powerful queries (stuff that the current language will never be able to accommodate), I will vote to do it in one of two ways:

1. Open up a JavaScript API that has access to the Task object and other relevant task list rendering fields, so users will be able to write their own logic in JavaScript, as I've seen done in many other plugins.
2. Focus on deeper integration with the Dataview plugin, which uses a completely different syntax than Tasks to express the same things. This means either to support in Tasks the Dataview syntax for dates and other metadata, or work with the Dataview developer to support the Tasks emojis as special custom fields. But this will allow to utilize the Dataview query language for tasks, including its very own JavaScript query variant.

[claremacrae]

Great - really helpful comments, thank you.

1. Open up a JavaScript API that has access to the Task object and other relevant task list rendering fields, so users will be able to write their own logic in JavaScript, as I've seen done in many other plugins.

Interesting. That is the subject of #913. A particular benefit of doing this would be to sharing the logic for handling recurring tasks, for example, so that other plugins could use this feature,

2 Focus on deeper integration with the Dataview plugin, which uses a completely different syntax than Tasks to express the same things. This means either to support in Tasks the Dataview syntax for dates and other metadata, or work with the Dataview developer to support the Tasks emojis as special custom fields. But this will allow to utilize the Dataview query language for tasks, including its very own JavaScript query variant.

Very nice idea too. Thank you.

[AnnaKornfeldSimpson]

@esm7 There was significant progress on 2. in Dataview 0.5.42-3 releases just very recently. Now Dataview supports querying almost all the Tasks emoji. See the updated Dataview documentation about the emoji shorthands for Tasks.

The only piece currently missing is recurring tasks support. I hope someone else will address that in the future!

[claremacrae]

I've done the initial implementation of this. The PRs are:

• refactor: Make tasks src directory structure match tasks-x #1118
• refactor: Rename tests/config/ to tests/Config/ #1119
• refactor: Rename Events.ts to TasksEvents.ts #1121
• refactor: Reformat code to match the format used by tasks-x plugin #1122

[claremacrae]

Also:

• refactor: Introduce new class TaskRegularExpressions #1123

[claremacrae]

Also:

• refactor: Capitalise the names of values in Status #1124

[claremacrae]

This work was all released in Tasks 1.14.0.