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.
The code handling the comparison between the date and string types would
convert the variants to correct types, but only through multi-level
fall-through in the switch statement, which is always a bit of a
dangerous construct.
Added explicit return for the non-trivial case, preventing the need for
the fall-through.
Closes#2502.
The feature has been moved to 3.0 milestone. Also, we are now using
feature branches for development of new functionality, in order to make
the development branch more stable.
This puts +PENDING at the same level of treatment as status:pending when
it comes to decision whether the data processed should be pending only.
The mechanism is by no means perfect and should be improved in the
future.
The detected command does not change once CLI2::analysis has been
performed. Cache the value of the command to avoid the need to
re-discover the correct value each time we're interested in it.
Canonicalization of attributes or attribute prefixes happens once per
every single task considered in the filtering process. It maps short,
prefixed names to their full-length versions, for example:
"pro" -> "project" in the expression "project:Home"
It follows that such process is not task-dependant and as such the
lookups can be cached.
