start date / t: / threshold / defer date / tickler entries support question

[amariusz]

Just found your app, looks amazing. Thank you!

Readme mentions start date feature:

* Todos can be enriched and searched for by
...
  - due dates
  - start dates

I've looked for it but couldn't find it. I couldn't find any related issue either.

If it's the case, do you consider implementing support for deferred entries? Hiding entries with future start dates (along with recursion) seems like a killer feature of OmniFocus that some todo.txt tools offer as well. Some may argue defer dates are much more useful than due dates.

I suppose "t:" attribute is well established todo.txt convention, but here are some links if this functionaly is not clear:

• https://github.com/mpcjanssen/simpletask-taskwarrior/blob/master/app/src/main/assets/index.en.md
• https://cdn.rawgit.com/bram85/topydo/master/docs/index.html#TagStart
• List of "Special tag / Additional Definitions" todotxt/todo.txt#8 (comment)
• https://github.com/FND/todo.txt-cli/blob/extensions/futureTasks

Note that deferring tasks may play very nice with recursion but implementation should be thought through. For example look at my comment here:

mpcjanssen/simpletask-android#312 (comment)

[zerodat]

@amariusz your request has lots of good information in it! Thanks for the pointers to the todo.txt, topydo and simpletask issues and discussions! I have used both topydo and simpletask, but wasn't familiar with the t: convention. It does seem like it is fairly widely supported in todo.txt tools.

This is of course up to @ransome1, but if no one objects, I would be able to implement the functionality of the t: threshold for the non-recurrence case quite easily in the filter expression scheme. It would just be a matter of supporting t: similarly to the support for due:. Happy to take a look at it this week.

The recurrence case is a little more complex. As discussed in the issues you referenced, it would mean updating the threshold in a similar way to what topydo does. I agree that the topydo behavior is better than the simpletask behavior in this regard. sleek already adds a due date to recurrences that lack one, but I would recommend not adding the threshold date unless the original todo already has one.

@ransome1, what do you think? Should I look into adding this feature?

[ransome1]

@zerodat it sounds like a very useful enhancement and if you have some time to take a look at it, I would highly appreciate it!

[amariusz]

Happy to read this :)

Regarding:

The recurrence case is a little more complex. As discussed in the issues you referenced, it would mean updating the threshold in a similar way to what topydo does. I agree that the topydo behavior is better than the simpletask behavior in this regard. sleek already adds a due date to recurrences that lack one, but I would recommend not adding the threshold date unless the original todo already has one.

I have yet to encounter a todo.txt tool that has this behaviour implemented in consistent manner ;) To be honest I don't like current sleek behaviour of adding due: attribute on completion of recursive tasks. It seems to me that recursion is common for routine tasks while due is rarely useful. I have hacked my topydo using following logic that works for me. Maybe you'll find it sensible too.

Here is what happens on completion of task with rec: attribute.

• strict mode
  • threshold present
    • due present
      • advance both t: and due: separately based on their values
    • due NOT present
      • advance threshold based on it's value
      • do not add due date
  • threshold NOT present
    • due present
      • Advance due date based on it's value.
    • due NOT present
      • No threshold and no due date. Just leave it as it is.
• non-strict mode
  • threshold present
    • due present
      • Calculate task lenght based on initial due / start date. Advance due date separately based on today's date. Set threshold so that start date/due difference is preserved
    • due NOT present
      • Advance threshold based on today's date. Do not add due date.
  • threshold NOT present
    • due present
      • Advance due date based on today's date.
    • due NOT present
      • No threshold and no due date. Just leave it as it is.

Update:

If there's no rec: task is marked as done and that's it.

BTW. Note that there also could be postpone action that's little different from defer. Maybe something to consider in the future and not to be confused. One can postpone due date by n-days, postpone threshold by n-days or maybe even postpone both preserving time difference. That's alternative to picking dates from calendar.

Here's how it looks like in OmniFocus:
https://discourse.omnigroup.com/t/quickest-way-to-delay-a-task/55945
https://support.omnigroup.com/documentation/omnifocus/mac/3.11/en/the-inspector/#dates

[zerodat]

@amariusz just wanted to mention (and it might be obvious to you already), but while you are waiting for this feature to be implemented, you could use a query like:

due <= today+2w or not due

for example. This will show you just the items that don't have due dates, or have due dates in the next two weeks. I realize that this isn't exactly the same thing especially for long tasks, but it works well for warning you about upcoming due dates without having to see everything in the future.

[amariusz]

Good to know. I didn't realize filter supports such queries.

[zerodat]

Yes, just to be clear, if you type that into the search box, it will filter your todo list according to the query. I'm proposing to add the threshold date to the filter query language, so that it supports similar operations on the threshold date as what it supports for due dates already. See Filter Expressions for Advanced Search · ransome1/sleek Wiki for more details on how it works right now.

[zerodat]

@amariusz I just updated the PR #197 to make recurrences work with t: dates.

It works as you outlined in your comment above, but I decided to stick with the behavior of adding the due: if there is only a rec: and neither t: nor due:. In that case, the rec would be a no-op, so adding the due date seems fairly harmless to me, and it is consistent with prior sleek behavior.

If there is a t: and a rec: with no due:, it will NOT add the due date, because the rec is presumably intended to update the t: date. I hope that this compromise is acceptable to you.
Thanks. 😄

[ransome1]

@amariusz , @zerodat this can be tested in https://github.com/ransome1/sleek/releases/tag/v1.0.9-rc.3

I gave it a quick look (no in-depth testing) so far and it seems to be working quite well. Once this feature is wrapped up I propose we put together a small wiki article because I think it can become handy for some users but it might not be very self explanatory. @amariusz Would you be interested in helping out on this

[amariusz]

@zerodat Preserving sleek behaviour in case of missing t: and due: seems like a smart choice here. I'm surprised how quickly this've got implemented :) Thank you!

@ransome1 I'll test this change today. Regarding wiki - I think it's a good idea. I've never updated one before but I should manage :)

[amariusz]

I've downloaded sleek-1.0.9-rc.3.AppImage, it starts but nothing happens after clicking buttons in the menu like "open file" or "settings'. Could you confirm this build is not broken?

[ransome1]

Yes you're right, the last merge removed a critical file, that hasn't been rebuilt with the last release. I'm going to fix it and create a new test release.

[ransome1]

@amariusz can you try again please? https://github.com/ransome1/sleek/releases/tag/v1.0.9-rc.3

[amariusz]

This one works, thanks.

[amariusz]

Glad to confirm all scenarios I listed above regarding tasks completion seem to be working fine. Good job @zerodat ! 🎉

Here are some additional notes I've made as I was playing around. Just for reference.

Related to this change

• 't' in filter field seems to work (t = ...)
• there's no date picker for 't' like for due (or icon, or filter setting like 'show tasks with threshold date in future') - maybe to consider in future

Notes unrelated to this change.

Funny support of incorrect dates e.g.

2021-07-12 task4 rec:+14d t:2021-07-62

changes to:

x 2021-07-12 2021-07-12 task4 rec:+14d t:2021-07-62
2021-07-12 task4 rec:+14d t:2021-09-14

Not sure if that was intented, but it's probably acceptable :)

Tasks with the same 'body' but different attributes get merged into one: e.g.

2021-01-25 task7 due:2021-02-08 rec:14d
2021-01-26 task7 due:2021-02-09 rec:14d

changes to:

x 2021-07-12 2021-01-25 task7 due:2021-02-08 rec:14d
x 2021-07-12 2021-01-26 task7 due:2021-02-09 rec:14d
2021-07-12 task7 due:2021-07-26 rec:14d

Sleek changes order of attributes / @tags in all lines on any update. Also removes empty lines. e.g.

## @@something h:1
2021-01-25 Test orgC rec:+14d t:2021-02-08 due:2021-02-08

changes to

## h:1 @@something
2021-01-25 Test orgC due:2021-02-08 rec:+14d t:2021-02-08

This happens only once and has benefit of file consistency but I believe such behaviour should be controlled by setting.

I miss option that would allow to turn off sorting like File order (unsorted) in Sort by section.

[amariusz]

Some more thoughts regarding this feature. The idea behind deferring is keeping entries out ouf the way until they become relevant. However right now it's only possible to hide them "on demand" with filter query. That's not very convenient.

I suppose following additions to View settings could enhance this feature usability:

• Show tasks with threshold date in future toggle
• Sort by: Threshold date
• Sort by: Threshold date in future
  • meaning e.g. 0 for current entries, 1 for future entries

[zerodat]

Thanks for merging and releasing this, @ransome1! I'll update the filter expression wiki page today to add the new filtering features.

I'm impressed with your careful testing, @amariusz . Here are some answers on the points you mentioned:

• yes, no date picker or other GUI features related to t: tags. Could be nice to have, but fortunately in todo.txt format you can just type them until you have specific GUI features.
• the loose handling of the illegal dates is kind of a javascript and jsTodoTxt feature, I guess, since neither one really tries to validate them or throw an exception. I have followed the same pattern in t: dates as was being done in due: dates. If you type the 2021-07-62 date into the Date object constructor in node you can see what I mean:

    $ node
    Welcome to Node.js v14.17.0.
    > new Date(2021, 07-1, 62);
    2021-08-31T07:00:00.000Z

• As you see July 62nd maps to August 31 and then you add two weeks to that in the recurrence. We should really do more checking of this in sleek, because if you add a new todo: testing task due:2021-07-62 it will show up under due date heading 2021-07-62, but with 2021-08-31 in the tooltip that pops up when you hover over the new task.
• in your example shown below, I think what happens is that a non-strict recurrence makes both of them due 2021-07-26, so they are in fact duplicates after being marked completed. Sleek doesn't allow duplicate identical todos. Probably should have two different descriptions task7 and task7a if you want to keep them separate, or at least use a strict recurrence to make sure they always have different due dates.

x 2021-07-12 2021-01-25 task7 due:2021-02-08 rec:14d
x 2021-07-12 2021-01-26 task7 due:2021-02-09 rec:14d
2021-07-12 task7 due:2021-07-26 rec:14d

• the behavior of sleek in ordering fields is a result of parsing with jsTodoTxt and then using the toString method to reconstruct the task, I think. So sleek will always produce a specific order after it processes a todo. This is helpful in comparing two tasks to see if they are duplicates, because todo.txt doesn't have any unique task identifier.
• the next thing I want to add to sleek is a named view feature so that we can save filters and sort options, and then quickly choose a view from a list. One option for filtering would be a filter query expression, which can already do more than any set of checkboxes and buttons. You could show tasks with threshold in future by making a named filter that contains the filter expression t > today. As you said, it would be good to be able to also sort by threshold dates.

[ransome1]

Regarding the GUI part I would suggest we add the toggle @amariusz proposed that either shows or hides todos, which threshold dates havn't been reached yet. I can take care of that. For the GUI I need a very short one or two word identifier to label to toggle. Something like "Threshold in the future" (which sounds horrible though ;)) Do you have any ideas?

Also if you like we can add a short paragraph to the help tab of "Dates", if you provide me one.

I'm going to skip on the sorting proposal though, because I want to focus the sorting on the attributes most todo.txt users associate with the todo.txt syntax. But I will add the treshold toggle to the Matomo tracking and if it turns out to be moderately used we can discuss the sorting option again.

[amariusz]

Thanks for explanations @zerodat. Named view is really promising feature.

@ransome1, I'd suggest following short names for that toggle:

• only available
• deferred items
• future items

I've prepared a draft for that wiki article. I couldn't find an obvious way to contribute it directly to this repo via pull request. You can find it here:
https://github.com/amariusz/sleek/wiki/Deferred-todos
It's not short. Feel free to freeze dry it.
Let me know if you want me to process it some other way

Thanks,

[ransome1]

@amariusz I added you as a contributor tot he sleek project and you should now be able to work directly in sleeks wiki. I also copied your wiki page. That's really good work on that article!

I'm not a native english speaker, but reading the title of the wiki page (Deferred todos) I was asking myself if this could be a self explanatory label for the toggle as well. What do you guys think?

[amariusz]

Thanks.
I'm not native english speaker neither but I guess "Deferred todos" is also a valid option.

[zerodat]

HI, @ransome1 and @amariusz. I'm a native English speaker. To me, the term "defer" is a bit confusing, because it means to delay something. But the threshold date doesn't delay the todo. Instead, it simply hides it from view until the specified date, and it only does that if you ask it to be hidden (using the filter expressions or the new switch that you are planning to add).

I suggest that the toggle should be labeled: Hide todo until t: date which should be quite clear.

[ransome1]

Thanks @zerodat, that sounds good in general, but can we somehow shorten it? The other toggles are reduced to as few words as possible and don't contain technical information like due:, t: or x. Also we need to stick to the off = hide and on = show system that the other filter toggles follow. Maybe something like Threshold in the future if this doesn't sound too confusing. At some point we can also add a little question mark to the labels and link it to the help modal.

[zerodat]

Do you propose to have it off=hide by default? I don't care, but note that the existing behavior is to show these todos, so you would be changing the default.

The problem with the word "threshold" is that it is not too meaningful, unless you are already familiar with this t: mechanism under this name. But I think not everyone uses the word "threshold" for this (maybe they say "start date" or "defer date"). By using t: in the label, I hoped to make it clear to casual users that this toggle relates to todos with a particular key that they might not be using yet. Anyone who uses the t: key will know exactly what that means and it is as short a label as you can get.

The new user will not know what Threshold in the future means, so I guess they will have to look it up in the documentation. If they just try it, it will not do anything because they probably don't have any t: dates in their todos.

[ransome1]

@zerodat I think the threshold filter/toggle should be on by default, so the deferred todos will be shown.

Do you think this could can be a compromise?

it is not the best solution, but it complies with the toggle logic and is consistent with the Due in the future toggle. The question mark would lead to @amariusz wiki page.

[ransome1]

@zerodat. As Defer is a verb, the toggle would mean that it defers dates somehow into the future right? Maybe Deferred dates in the future or simply Deferred dates could be an option as well. As Defer is not referencing the todo but the date now, it might make more sense. What do you think?

So the system would be:
Completed: Show or hide todos that are completed
Overdue: Show or hide todos that are overdue
Hidden: Show or hide todos that are hidden
Deferred date: Show or hide todos that have a deferred date

[zerodat]

@ransome1 I think that the question mark button is probably a good thing to do, because none of the labels is likely to be clear to someone who hasn't encountered the t: feature before.

As for the label, it shouldn't be just Defer date or Deferred date, because it isn't whether it has a t: date but rather whether that date is in the future. So it is more like the Due in the future.

Defer date in the future is not too bad, but I'm not crazy about the term "defer date". I think I'd prefer Threshold date in the future or maybe Visibility date in the future. But it's up to you, and doesn't really matter to me. Personally I will make all todos visible and use the filter query expression language anyway. 😄

[ransome1]

Ok, let's start this with Threshold date in the future. It's not ourboth favorite, but it sticks the toggle logic and it contains the word t: is the abbreviation for. If we think of something better, we'll just change it in the future.

Filter query expression language. So nerdy, so cool ❤️

@zerodat Would you say the feature is ready for deployment? If so I'm going to prepare the 1.0.9 release.

[zerodat]

Yes, @ransome1 it seems like the threshold feature is working in 1.0.9 release candidate 4.

[amariusz]

I'm ok with any name that's already present in other tools. SimpleTask uses 'threshold', OmniFocus uses 'defer'.

t: is used by convention to provide compatibility with other tools. I wish someone named this attribute def: in the past.

As for the label, it shouldn't be just Defer date or Deferred date, because it isn't whether it has a t: date but rather whether that date is in the future. So it is more like the Due in the future.

There's other way to look at it - item with t attribute is either deferred or current depending on attribute's value and current date :) So 'Deferred' toggle could do the trick as well.

That's just a comment. I really don't care so much about the name. It may be changed in future after feedback from users.

[amariusz]

Personally I will make all todos visible and use the filter query expression language anyway.

..and by the way named view feature you mentioned above is called "Saved filters" in SimpleTask and "Custom perspectives" in OmniFocus.

[ransome1]

The feature has been released in https://github.com/ransome1/sleek/releases/tag/v1.0.9

[amariusz]

@zerodat @ransome1 Yey! Thank you very much for delivering this feature! 🎉

[ransome1]

@zerodat yep, big thanks to you. Again :)

[amariusz]

Regarding information in README.md that initially confused me

* Todos can be enriched and searched for by
...
  - due dates
  - start dates

I suppose it should say creation dates not start dates.

https://github.com/todotxt/todo.txt

[ransome1]

I suggest we close here. I added Github discussion where we could continue discussing this feature and collect ideas for a follow up feature request if needed.