Every configuration parameter can be overwritten for the
current context by setting the parameter:
context.<name>.rc.<parameter> = <value>
in the config file. This allows for example to set a custom
report for each context.
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
This patch allows e.g. due.by:tomorrow that includes all of tomorrow,
because it uses less than or equal to, rather than just less than, like
'before' modifier does. This allows matching the last second of the day
when filtering by "due.by:eod", and more generally allows date filters
with an inclusive end-interval specification.
Closes#2536
Instead of relying on the modification times, we can use the values of
the start and end attributes, if available.
This allows us to perform historical changes that result in correct
duration intervals reported by task info.
Closes#2514
Since annotations are stored as a map, duplicate entry values lead to
data loss (i.e. annotations overriding each other on import). Perhaps
the choice of using a map internally should be reconsidered.
Closes#1938.
