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.
This would be immediately useful to improve the rendering of the man
pages in third-party websites such as manned.org and the arch man pagesk
- https://mankier.com/1/task
- https://man.archlinux.org/man/task.1
The regular console output, or websites which render the manpage in
monospaced fonts, will not be affected by this change.
This change could also help with eventually rendering the manpages in
the documentation website, and having a mix of monospaced and variable
width fonts.
To test the HTML output:
```bash
git clone git@github.com:jacksonp/manner.git # used by ManKier
./manner/manner.php task.1.in >| task.1.html && $BROWSER task.1.html
```
Co-authored-by: Sebastian Carlos <sebastiancarlos@gmail.com>
* 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
This crate has been moved to
https://github.com/GothenburgBitFactory/taskchampion-sync-server.
The integration-tests repo used the sync server to test integration
between taskchampion and the sync-server. We should do that again, but
after taskchampion moves to its own repo (#3209). In the interim, the
cross-sync integration test can simply test syncing between local
servers, but the snapshot test is no longer useful as the local server
does not support snapshots.
* Recommend LSP's in development docs
Per conversation in #3338.
There are already a lot of documented compile options so I think we're
better off suggesting that everybody create a compile_commands.json
whether or not they're using an LSP because it doesn't cost much.
While I was at it it seemed reasonable to mention rust LSP too. Now that
rls is deprecated I'm not sure there is any competitor to rust-analyzer
worth mentioning.
* Export compile commands by default.
Thanks to @felixschurk for the idea and telling me how to do it.
It took me a minute to figure out that this places the
compile_commands.json in the build directory rather than the root of the
project. But clangd still finds it there and that's a better place for
it anyway.
* update build instructions
Usage of "modern" CMake syntax and using specific out of source build.
Further add example on how to build in parallel, build a specific target
and how to change the compiler.
This closes#3236.
* Add support for cloud sync, specifically GCP
This adds generic support for sync to cloud services, with specific
spuport for GCP. Adding others -- so long as they support a
compare-and-set operation -- should be comparatively straightforward.
The cloud support includes cleanup of unnecessary data, and should keep
total space usage roughly proportional to the number of tasks.
Co-authored-by: ryneeverett <ryneeverett@gmail.com>
* move doc/misc to top level, add READMEs
* Move docs -> doc/devel
This also consolidates the _three_ documents describing (differently)
how to build Taskwarrior into a signle document.