Internal: Better abstraction for grouping of tasks

[claremacrae]

There are some missing capabilities for group by, which are caused by my naive initial implementation.

Missing abstraction for the sort order of group headings

Specifically, the biggest behavioural weakness in the current grouping is that all the group names are sorted alphabetically, which is a blocker for grouping by urgency, for example - see the screenshots in: #788.

It also leads to this oddity in the group by status docs - just because of the text sort order:

Note that the Done group is displayed before the Todo group, which differs from the Sorting ordering of this property.

Inability to do group by [blah] reverse

Also, some users would like to reverse the sort order. For example, several people reported that group by [date] broke sorting, as they expected.

I can'd find the reference, but a couple of people have expected to groups in reverse date order by doing this:

sort by due reverse
group by due

Because sort's job is to sort tasks within groups, now, I was thinking that the right answer would be to do:

group by due reverse

Later: here is where I wrote up reverse-grouping-order previously: #780.

Implementation thoughts

These are half-baked, but it's what I've got...

I recently-ish divided out many hundreds of lines of filtering code from Query in to DueDateField etc in src/Query/Filter/

The reason I called these Field rather than Filter is that I was hoping to make the next step to migrate the methods from Group and Sort classes in to the various Field classes.

Or, to put it another way, I was hoping that the ordering of groups in group by could piggy-back off the already-tested code, including reversal, in sort by.

Intention/goal;

I would love to make it so that adding a new row to Quick Reference - for a new property - would be a matter of:

• providing a new Field class for it, and making sure that the filter, group name and comparison function were correct.
• adding tests for the above (or the other way round!)
• adding the new commands to the Query tests as integration tests
• And updating the docs
• Then doing the release

[claremacrae]

@MohamedBassem - possibly of interest...

[bryanwhiting]

+1 The first thing I tried doing when group by tags was reverse the tag 😀. I like the implementation "group by reverse" because then "sort by" would keep the focus on sorting the tasks within the groups.

If you wanted to sort tasks across groups then it wouldn't make sense to group by. Having the ability to sort the groups and sort the tasks within the groups separately would make this plugin extremely powerful. I don't know of any other task manager that can do that...

[claremacrae]

Thanks @bryanwhiting...

Just to set expectations. I'm thinking this is about refactoring the current grouping code, so that the behaviour is unchanged but the code is more flexible/powerful.

Then separate PRs would actually implement the missing features.

[claremacrae]

I wrote up some notes on how to finish off the initial refactoring I did of grouping, to start migrating the grouping code to the Field classes.

1. Add filtering, sorting and grouping for created date #1741 (comment)
2. refactor: Rework group-naming code for future improvements #1549 - the description has an explanation of the new interface for grouping in Field classes
3. feat: Add 'group by status.name' #1550 - example implementation
4. feat: Add 'group by status.type' #1553 - example implementation

[ilandikov]

@claremacrae as discussed today, this may be closed =)