This replicates what the Rust runtime does, and matches what Rust code
expects, for example when writing to a socket which is no longer
connected to the remote end.
TC 0.7.0 introduces a new `TaskData` type that maps to Taskwarrior's
`Task` type more cleanly. It also introduces the idea of gathering lists
of operations and "committing" them to a replica.
A consequence of this change is that TaskChampion no longer
automatically maintains dependency information, so Taskwarrior must do
so, with its `TDB2::dependency_sync` method. This method does a very
similar thing to what TaskChampion had been doing, so this is a shift of
responsibility but not a major performance difference.
Cxx is .. not great. It is missing a lot of useful things that make a
general-purpose bridge impractical:
- no support for trait objects
- no support for `Option<T>` (https://github.com/dtolnay/cxx/issues/87)
- no support for `Vec<Box<..>>`
As a result, some creativity is required in writing the bridge, for
example returning a `Vec<OptionTaskData>` from `all_task_data` to allow
individual `TaskData` values to be "taken" from the vector.
That said, Cxx is the current state-of-the-art, and does a good job of
ensuring memory safety, at the cost of some slightly awkward APIs.
Subsequent work can remove the "TDB2" layer and allow commands and other
parts of Taskwarrior to interface directly with the `Replica`.
Taskwarrior uses "expire" to refer to deletion of tasks past their
"until" date, so let's use `purge` to link this semantically to the
`task purge` command.
Tasks can be due "today", as `task add foo due:today ..` is a common
form. However, recurrences before that are just not created.
This avoids a lengthy "hang" when recurrences are updated on an old task
database, as many tasks in the past are created.
Consistently exclude WAITING tasks from reports which filter by status
If I understand correctly, the virtual status "waiting" is deprecated.
This is why some reports include the explicit "-WAITING" filter even
though it is not necessary: The idea is that being explicit will be
needed in the future when the "waiting" status is removed.
But I noticed that some reports do not include the "-WAITING" filter, so
I added it to all reports that filter by status.
This has the effect that `task news` will unconditionally update the
config with the new version once news has been shown (assuming the user
does not kill the process first).
* Only warn about .data files when showing reports
This avoids the warning appearing in shell completion, for example.
* Update src/commands/CmdCustom.cpp
Co-authored-by: ryneeverett <ryneeverett@gmail.com>
---------
Co-authored-by: ryneeverett <ryneeverett@gmail.com>
Update condition for inheritance value hack
If the parent and child task have the same urgency the parent task also
needs the 0.01 extra urgency to be sorted above the child.
* remove symbollic links in the src directory as they are no longer
working with the out-of-source build
* remove .gitignore in the documentation (is build in build folder not
needed)
* remove CMake folders as they are also no longer present in the source
directory
Closes#3420.
* move taskchampion-lib to src/tc/lib, remove the rest
* update references to taskchampion
* Use a top-level Cargo.toml so everything is consistent
* apply comments from ryneeverett
The on-exit hook gets all modified tasks as input, but this was omitted
in the previous release. This adds a test for the desired behavior, and
updates TDB2 to correctly store the required information.
This will enable nixpkgs -- and any other distribution that builds in a
network sandbox and/or wants to use their own corrosion package rather
than building another one -- to do so without patching taskwarrior.
Since we're already using submodules for libshared I don't think this
should make the build process any more complicated for anyone else.
See
https://github.com/NixOS/nixpkgs/issues/300679#issuecomment-2041252688
for context.
