Allow only leading spaces in front of configuration variables, as
opposed to arbitrary strings.
This prevents matching variables like "report.list.context=" when one is
seeking to modify "context=".
This also drops support for the transitional `json.depends.array`
configuration value, which has not been necessary since ~2016.
As with tags, dependencies are stored in both a "combined",
comma-separated format (for compatibility) and in an
attribute-per-dependency format (for the future).
Each tag is stored as `tag_<tagname>: x`. The `x` is required because
empty attributes are treated as nonexistent.
For compatibility, the `tags` attribute is updated in sync with the
per-tag attributes. This compatibility support may be dropped in later
versions.
Note that synchronization _updates_ use JSON format, which does not
change with this patch, and thus no compatibility issues exist. The
synchronization _initialization_, however, uses FF4, meaning that a
sync server initialized from a version of `task` with this patch will
contain `tag_<tagname>` attributes, which will look like orphaned UDAs
to older versions. However, as updates to tasks are synchronized via
the sync server, the updates will not contain these attributes and they
will show as "deleted" in the `task info` display on the older version.
Aside from the noise in the `task info` output, this is harmless.
With this patch, taskwarrior uses the urgency of tasks before any
modifications are applied when deciding whether to show nag messages.
Previously, taskwarrior would apply modifications before deciding
whether to show nag messages, which could lead to spurious nag messages
when completing an active task.
without the fix, when listing out the tags we would see output like:
Virtual tags PENDING PROJECTREADY TAGGED UDA UNBLOCKED
there isn't a PROJECTREADY tag of course, but rather a missing space
Since 'task edit' is a data-modification operation (that is particularly
hard to cancel mid-way), it should also respect the 'bulk' option like
all the other modification operations (mod, start...).
Closes#2428.
Previously, if no due date was set on any pending/waiting task, the
calendar output would start at the end of the currently supported date
period.
Default to current month instead.
The purpose of displaying due dates on the calendar is to convey the
relative business of any given day. Waiting status signifies a task
should not be displayed in reports yet, but for the purposes of
planning, it should be displayed in the calendar overview.
Closes#2393.
Since e4b9c1f annotations where JSON encoded in task edit to escape
new lines (\n). But other strings where mangled as well, like https://
becoming https:\/\/, making it hard to edit.
This patch removes the JSON encoding and indents new lines instead.
