Add support for 'waiting' task status marker

[kevinstadler]

This PR adds a marker for 'waiting' tasks, one of the 5 mutually exclusive task states which was previously not supported for marking.

Just for sake of completeness, here is the current support for marking of tasks in each of the 5 possible states:

• completed already supported (determined via task status)
• deleted already supported (determined via task status)
• waiting implemented by this pull request (also determined via task status)
• recurring already supported but internally this is done by checking the recur field, rather than the status (a task's status is recurring iff the task has a recur: date):

  vit/vit/formatter/markers.py

  Lines 20 to 21 in 1d59db8

  	if self.mark_recur and task['recur']:
  	width, text_markup = self.format_recurring(width, text_markup, task['recur'])

  )
• pending tasks can't currently be marked, but this is sort of the default/'unmarked' state of tasks so possibly superfluous to add support for a marker for it?

[thehunmonkgroup]

Can't get this to work. Couple of problems I notice:

1. There seems to be some confusion between the wait property and the waiting status that's set as a result of the wait property being set.
2. wait is missing from MARKABLE_COLUMNS in markers.py?
3. wait also seems to be missing from this list in the sample config.ini:

   # What columns to generate markers for. Can either be 'all' for all columns, or
   # a comma separated list of columns to enable markers for. Possible columns
   # are:
   #  depends,description,due,project,recur,scheduled,start,status,tags,until
   

If I'm missing something, please feel free to enlighten me.

[kevinstadler]

Ah yes, I can see now that the current set of markers I was looking at are actually replacements for different columns:

• completed and deleted provide a sub-set of the information of the status column, so they are hidden whenever the status column is visible
• recur is for the recur column, which is set for both the original (parent) recurring task and its (child) repetitions. This doesn't map directly onto status:recurring, because only the parent task has this status, child tasks are in one of the usual (pending, completed, deleted, waiting) states. There is currently no marker support for parent recurring tasks.

So in terms of the marker for waiting tasks it actually looks like having a non-zero wait date and status:waiting are almost the same. There is only one case where a task can have a wait: date but not be status:waiting, namely if a task is the original (the parent) of recurring task (i.e. has status:recurring), but also has a wait: date specified which is actually not a 'true' wait date, but just a (relative to the add/due date) template date that is copied over to the child tasks (which will actually stay in status:waiting until the wait: date has expired).

That is literally the only case I could find where 'having a wait: date' and status:waiting differ. When a task is completed or deleted the wait: is removed, same when the wait: date passes (which turns the task into status:pending).

So I think the basic question is: should the 'wait(ing)' label only be applied to status:waiting tasks, or also include recurring parent tasks which have a wait: set?

Once we've answered this question we'll automatically have answers to the following:

1. which column the display/non-display of the marker should depend on (status or wait)
2. whether the config option for it should be named waiting.label (referring to status in the same way as completed and deleted do) or wait.label (referring to the task's wait column, similar to what the recur label does)

Personally I'm strongly leaning towards the first option here, as I wouldn't consider the parent template of recurring tasks as truly 'waiting'. So I'd favour a waiting.label which is only shown whenever the status column is not visible, which is in line with what the completed and `deleted labels do. Any thoughts?

[thehunmonkgroup]

Yep, first option makes sense to me, let's do it.

[kevinstadler]

So in that case I don't think anything needs to be added to the MARKABLE_COLUMNS or sample config, as waiting.label is a marker of the already-included status column, rather than of the wait column.

Wondering why the label isn't showing up on your side though, do you have status set to be a markable column?

[thehunmonkgroup]

I'm a little short on time right now to debug. Think you can put together a dummy install using https://github.com/vit-project/vit/blob/2.x/scripts/generate-dummy-install.sh and a working .taskrc, and attach them to this PR?