* Declare in corresponding header files and dissolve main.h
Apply include-what-you-use
* Remove further unncessary includes
* Incorporate review comment
* Do not declare static functions and variables in header
* Adapt test
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* Test for unusual task data
A task might have any combination of keys and values, but Taskwarrior
often assumes that only valid values can occur, and crashes otherwise.
This is highly inconvenient, as it's often impossible to do anything
with the invalid task -- Taskwarrior just fails without modifying it.
So, this is the beginning of some testing for such invalid tasks, with
the goal of making Taskwarrior due something reasonable. In general, an
invalid attribute value is treated as if it was not set. This is not
exhaustive, and there are likely still bugs of this sort, but as we find
them we can fix and add regression tests to this script.
This introduces a new test-only binary that creates a "bare" task using
TaskChampion, avoiding Taskwarrior's efforts to not create "unusual"
tasks.
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
This centralizes updates to recurrence and 'until' in Command, instead
of doing so in each individual command implementation.
This is preparatory to opening the TaskChampion replica in read-only
mode.
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.
- new-uuid is *not* set by default
- new-uuid overrides new-id when set
The reasoning is that new-uuid is mostly used by code (eg: Python's
taskw module), whereas new-id is mostly used by humans.
By making new-uuid not set by default, calling code can set it to
receive UUIDs (preserving 2.5.x behaviour), but humans can continue to
use integer task IDs.
- Many files were missing an explicit cmake.h include. Some were not including
it at all. Now it's used almost everywhere.
(cherry picked from commit 82ae86979c497e6d1d0c6b2b5a55aa379ec82c98)