support for 'wait' attribute

[gour]

Hello,

What do you think about adding 'wait' attribute (ala taskwarrior's feature) to allow the task be hidden until certain date in order not to clutter's our agenda before it's due?

[tionis]

This would especially be useful to implement GTD in dstask in the style of this article:
https://cs-syd.eu/posts/2015-06-28-gtd-with-taskwarrior-part-3-tickling.html

[Dieterbe]

This also came up in #54 , i think there is consensus to have a "only start working on the task after " directive which, notably, is something else than "task must be completed before " . For the latter I think we'll proceed with the "Due" terminology.

For the former, "defer" seems to be preferred terminology. I want this, so might give this a shot. Although before I start,

• Due date #54 (comment) (question for naggie here)
• I wonder what the UX should be. for tasks with a "defer date" in the future, should they just not appear in the "next", "show-open", "show-resolved" commands etc? If so, should we offer a separate flag to include them in the output? Or should we show them in a separate section? If so, how do we make that work with the json output?

I personally like the idea of not being distracted by tasks with future defer dates, and thus not showing them by default.

What if we implemented "magic tags" ?
Imagine if you could use +deferred or +future in your filter/query expression include such tasks. or deferred:future (similar to project:foo selectors). It seems to make sense to make the query the "one stop shop" to declare which tasks you want to see. No need to worry about separate flags. We already have the behavior that a DSTASK_CONTEXT environment variable is "extended" by further query keywords on the commandline, and this seems to play into that nicely'

[naggie]

* I wonder what the UX should be.  for tasks with a "defer date" in the future, should they just not appear in the "next", "show-open", "show-resolved" commands etc?  If so, should we offer a separate flag to include them in the output? Or should we show them in a separate section? If so, how do we make that work with the json output?

I suggest we indeed hide them from view by default. I suggest a new command show-deferred to list them, and a text info message to indicate there are some where the current summary is. Eg:

22 tasks, 3 deferred hidden in this context. Run show-deferred to see them.

I personally like the idea of not being distracted by tasks with future defer dates, and thus not showing them by default.

Me too.

What if we implemented "magic tags" ? Imagine if you could use +deferred or +future in your filter/query expression include such tasks. or deferred:future (similar to project:foo selectors). It seems to make sense to make the query the "one stop shop" to declare which tasks you want to see. No need to worry about separate flags. We already have the behavior that a DSTASK_CONTEXT environment variable is "extended" by further query keywords on the commandline, and this seems to play into that nicely'

I'm not sure about magic tags, I like the idea of tags being unsurprising and straightforward. So far, current filters + a special command has worked well. I think if we want to extend the query language (or special tags) to allow for searching task type, we should replace these specific commands. I think there's no need for that kind of refactor now.

[Dieterbe]

I suggest a new command show-deferred to list them, (...) So far, current filters + a special command has worked well. I think if we want to extend the query language (or special tags) to allow for searching task type, we should replace these specific commands

I note that we currently mix show-<foo> commands for various purposes:

1. select tasks by state, regardless of whether they're organized or not (show-active, show-paused, show-open, show-resolved)
2. select tasks based on other criteria, regardless of state (show-unorganised)
3. select other things (show-projects, show-tags, show-templates)

I think your proposal for show-deferred is fine (would fit in category 2), but it does seem we're overloading the show-<foo> convention for a variety of things that have nothing to do with each other. (in particular, a task may be "organized" or "unorganized" and yet have any of the task states, and likewise for being deferred or not, having a set of distinct show commands implies that they're all distinct states)
But I think that's fine, and i'm not ever worried about doing a refactor. I think it's fine to have e.g. a show-deferred that shows tasks of all different states (without being able to specify filtering for deferred status AND task state), just like show-unorganized does

I like your idea of the text message, but I note that if you ran, e.g. show-active and got:

22 tasks, 3 deferred hidden in this context. Run show-deferred to see them.

If you then run show-deferred, you would see all deferred tasks in the context, regardless of the state, so possibly way more than 3. Is that OK? (I presume the 3 here is deferred active tasks, and not all deferred tasks in the context)
I guess this brings up another question: can a task with future defer date only be started/opened/paused/resolved once the defer date has passed?
Or perhaps when starting/pausing/resolving a task with future defer date, we should drop the defer date, such that a task can only be deferred when it's still pending?

IMHO the right answers here are yes, no, no.