* Do not auto-create .taskrc when stdout is not a TTY
This avoids prompting or automatically creating such a file, both of
which are unexpected when performing command-line completion.
Fixes#3751.
* Test case for taskrc creation no longer works
A taskrc is only created when stdout is a tty, which would require
allocating a pty, which is very platform-dependent and definitely not
worth the trouble for this test.
* 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>
* Remove unused include in Variant.h
* Remove unused include in util.h
* Remove unused include directives in util.cpp
* Remove unused include directives in TF2.h
* Remove unused include directives in TF2.cpp
* Remove unused include directive in TDB2.h
* Remove unused include directives in TDB2.cpp
* Remove unused include directives in Task.h
* Remove unused include directive in rules.cpp
* Remove unused include directives in rules.cpp
* Remove unused include directives in nag.cpp
* Remove unused include directive in main.h
* Remove unused include directive in legacy.cpph
* Remove unused include directive in Hooks.cpp
* Remove unused include directive in Filter.h
* Remove unused include directive in Filter.cpp
* Remove unused include directive in feedback.cpp
* Remove unused include directive in Eval.cpp
* Remove unused include directives in dependency.cpp
* Remove unused include directivess in Context.cpp
* Open Replica read-only when possible
Specifically, when either
- the command is read-only; or
- the command requires GC (including recurrence updates) but GC is disabled by config
* [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.
* libshared: bump for weekstart, epoch defines, eopww fix
mainly those visible changes, and miscellaneous others
see GothenburgBitFactory/taskwarrior#3623 (weekstart)
see GothenburgBitFactory/taskwarrior#3651 (epoch limit defines)
see GothenburgBitFactory/libshared#73 (eopww fix)
* Initialize libshared's weekstart from user's rc.weekstart config
This enables use of newer libshared code that can parse week numbers
according to ISO8601 instead of existing code which is always using
Sunday-based weeks. To get ISO behavior, set rc.weekstart=monday.
Default is still Sunday / old algorithm, as before, since Sunday is in
the hardcoded default rcfile.
Weekstart does not yet fix week-relative shortcuts, which will still
always use Monday.
See #3623 for further details.
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.
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.
* 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>
In #3118 @ryneeverett mentioned that "key" suggests that this is a
secret, when in truth it's just a user identifier. So "ID" is a better
word for it than "key".
This removes use of gnutls and the TLS implementation, which is no
longer needed (task synchronization is handled via Taskchampion, which
uses `reqwest`, which handles TLS via other Rust dependencies). This
incidentally removes the following config options:
* `debug.tls`
* `taskd.ca`
* `taskd.certificate`
* `taskd.ciphers`
* `taskd.credentials`
* `taskd.key`
* `taskd.server`
* `taskd.trust`
This is a corner case bug, when user has both old-style and new-style
context defined, where new-style is defined as empty string, the
old-style will (incorrectly) take precedence.
Closes#2629.
