Due to not accounting for the leading "P", getNextRecurrence would always return the same datetime, breaking all generic "PnM" periods and leading to an infinite loop in generateDueDates.
The test was failing because it expected "Created task 1"
but it saw "Created task 0a436fd8-7f06-4168-a66d-bbc940498af9".
Instead, the new code looks at the description of task 1.
This fixes a regression was introduced in
4e80d5d5fd.
Currently, if a user (with default configuration) adds a completed or
deleted task, they do not get a confirmation message ("Created task
..."). This is due to the fact that:
a) new-uuid is not set by default
b) new-id is set by default, but only prints message if the added task
is in pending or waiting state
Make sure to print a message containing UUID reference if the newly
added task is in completed or deleted state.
This fixes a regression was introduced in
4e80d5d5fd.
Currently, if a user (with default configuration) adds a completed or
deleted task, they do not get a confirmation message ("Created task
..."). This is due to the fact that:
a) new-uuid is not set by default
b) new-id is set by default, but only prints message if the added task
is in pending or waiting state
Make sure to print a message containing UUID reference if the newly
added task is in completed or deleted state.
This addresses #2023
For many years linewrap has been broken in taskwarrior, rendering the
application basically useless in terminals with short widths and tasks
containing URLs in them... This janky line wrap patch sort of works but
introduces other minor graphical glitches.
But seeing as no one took the time to fix it over the years, here some a
small salvation to those who suffer as much as me.
One problem of this patch is, when a line is wrapped, it may be 1 column
smaller than the terminal width, resulting in each line not fully
utilizing the terminal width.
This patch is not polished and could probably need to be tended by
someone who cares more.
The test was failing on my machine on fresh checkout. It failed because
somehow both new-id and new-uuid verbosity were set during the test, so
TW defaulted to printing out uuid, which did not match the assertion.
Test fixed by explicitly setting verbosity to new-id.
