feature request: list the overdue, today and soon items only at once

[eugnma]

Currently the only way to list overdue, today and soon items only is passing 3 commands:

• ttdl list --due overdue
• ttdl list --due today
• ttdl list --due soon

It's OK for manually checking, but it's hard to generate a summary for external program, is it possible to support the feature? Thanks!

BTW, there's possible an issue for overdue filter, it doesn't display the 2020-07-01 Test due:2020-07-14 rec:1m item if the current date is 2020-07-15.

• [x] implement custom flexible filter for due date (in addition to existing soon, today etc)
• [x] add a section to docs about filter (it gets a bit complicated, so it needs its own detailed description)

[VladimirMarkelov]

I agree, it sounds useful. The only things we have to discuss are:

1. What command displays the list? To me a good way to do it is passing --due without argument(ttdl list --due). Though, I am not sure whether it is possible, so I'd like to have more choices. Maybe --due all or --due any. One more option: rename current overdue, today, and soon to only-overdue, only-today, and only-soon and make the current words to show all due dates that are included in the interval(e.g, soon shows all, while today shows only overdue+today
2. How to display them? Just a standard list, or sorted by due date, or sorted by due date and grouped by due type?

2020-07-01 Test due:2020-07-14 rec:1m - I'll check this one

[eugnma]

Is it possible to use a command like ttdl --due overdue,today,soon? The output should keep the current behavior, it just filter the items, and the output can be sorted by other supported arguments.

[VladimirMarkelov]

Multi-choice? I did not think about it. A good idea. In this case it seems more flexible. I'll do it this way.

[obbardc]

I just thinking about this myself and thought that --due could accept CSV and AND them like --due today,soon or AND multiple arguments --due today --due soon. both ways would be nice

[VladimirMarkelov]

BTW, there's possible an issue for overdue filter, it doesn't display the 2020-07-01 Test due:2020-07-14 rec:1m item if the current date is 2020-07-15

It is fixed in today's master. You were right - it was overdue filter issue, unrelated to recurrent todos.

[VladimirMarkelov]

As of --due today,soon, after implementing human-friendly due date setting, it dawned upon me that I can make due date filter more flexible. Listing all required due types maybe error-prone and this way is still rigid(it allows a user to choose from a limited set of combination, most of them are useless).

Feature preconditions(what makes me to invent a new way):

1. A user almost always needs a contiguous list. E.g, listing at the same time only overdue and tomorrow todos is very unlikely case
2. If a user wants to see todos with due none , it is very unlikely that in the same list the user wants to see, e.g, overdue todos.
3. Even having 5 due types(overdue, today, tomorrow, soon, none) may be insufficient. E.g, I think it is not too rare to want to list todos that are due in a week or in half a week. Yes, it is can be done with modifying soon value in config and displaying --due soon but it is inconvenient.

Taking those bullets into account, I decided to use ranges(I think it is good to support two syntax definitions that are used in Go/Python and Rust to get a string slices. With one difference: due range is inclusive for both ends). Rules are:

• old values keep working in the old way - no changes
• extend single value with human-friendly ones (e.g, --due 3d - lists todos with due date in three days from today)
• use ":" or ".." to define a range(examples: --due ..soon lists all todos that are overdue or due soon, --due today..3d lists only todos that are due only between today and 3 days in the future, overdue ones are not included, --due tomorrow.. lists "future" todos that can wait)
• I think open ranges should be noninclusive . Because for --due soon... one may expect that it means everything after soon. Making open ranges inclusive creates overlapping that may be not good (e.g, --due today..soon and --due soon.. should show different lists. If all is inclusive, soon.. includes soon and today..soon does it as well). Though, it may be confusing: e.g, it makes --due overdue and --due ..today synonyms)

What do you think?

If it looks good, later I can extend this type of filter to create and finish dates, so one can list,e.g, todos created last week, or completed yesterday. It may be useful at times (e.g, to generate a report about what has been done last week ;) ).

[eugnma]

Great news! I agree with it.

[VladimirMarkelov]

Almost done. I have to update docs(README & built-in help) and then I will release version 0.10.0 with date ranges for all date-like fields(due, theshold, creation, finish).

[VladimirMarkelov]

It seems working. Feel free to open an issue(or reopen this one) if something works wrong ;)

[eugnma]

Seems like it doesn't support ttdl --due ..soon.

[thomasjfox]

Seems like it doesn't support ttdl --due ..soon.

ah yes, looks like human_date::special_time_point() needs support for "soon". It supports most other special times except that one.

Workaround: ttdl list --due=..7d

[VladimirMarkelov]

Yes, it is was done by intention. And I was not sure whether I have to add soon support to range. The trouble was that soon is the only very special thing that is already a range. Really, --due soon internally converts into a range --due today..7d. Making it an end of a range raised a few questions like: "If due=soon is due=today..7d, what means due=tomorrow..soon? Should it shrink the range to tomorrow..7d?". That was why I ignored soon in range parser.

But if you think, due=soon, due=..soon, and due=2d..soon are unambiguous, I'll add support for soon in range as well.

[VladimirMarkelov]

The current version 0.10.1 should work with soon, <any>..soon, and -soon..<any> as expected. In ranges soon becomes a synonym for #d where # is either value from config or 7 if config value is zero.

[thomasjfox]

Thanks Vladimir for those superfast fixes! It's highly appreciated. TTDL was great before and now it became even more convenient to use.

I tried this:

$ ttdl l --due=overdue
 # D P Created    Finished   Due        Subject
------------------------------------------------
64   A 2020-07-20            2020-07-24 feed hamster
------------------------------------------------
1 todos (of 80 total)

$ ttdl l --due=overdue..soon
invalid value invalid date 'overdue' for date range

Did I do something wrong here?

[VladimirMarkelov]

Oh, I forgot about this very special day that is also a range(more accurate, it is an open range: due < today). The example above can be simplified to --due=..soon. But for case overdue..tomorrow there is no simple alternative.

I can add this rule: in a range treat overdue as a big negative value, so --due=overdue..soon would be converted internally to--due=-365d..7d(365 is questionable, but it is here for example) . I think it is a good enough solution. Additional rule: overdue as well as yesterday cannot be used for the future dates, so --due=-overdue generates an error. It seems reasonable.

[VladimirMarkelov]

But for case overdue..tomorrow there is no simple alternative.

As a second thought, any expression with overdue(overdue..<date>) can be simplified to an open range ..date). So, adding overdue may make things a bit more convenient(no need to remember when to use closed range and when to use open range), but does not add any new stuff

[VladimirMarkelov]

Added overdue support in ranges. To make calculation simpler, overdue is just a certain date that is 10 years ago from today. I think the approximation is good enough :) I'll release 0.10.1 a later today

[eugnma]

Awesome!