With checksum

try to explain the intentions of the fork

.cargo/audit.toml

@@ -1,6 +0,0 @@
-[advisories]
-ignore = [
-    "RUSTSEC-2021-0124", # see https://github.com/GothenburgBitFactory/taskwarrior/issues/2830
-    "RUSTSEC-2020-0159", # segfault in localtime_r - low risk to TC
-    "RUSTSEC-2020-0071", # same localtime_r bug as above
-]

.clang-format

@@ -1,5 +0,0 @@
----
-Language:        Cpp
-BasedOnStyle:  Google
-ColumnLimit:     100
-...

.devcontainer/Dockerfile

@@ -1,20 +0,0 @@
-FROM mcr.microsoft.com/devcontainers/cpp:1-ubuntu-22.04
-
-ARG REINSTALL_CMAKE_VERSION_FROM_SOURCE="3.22.2"
-
-# Optionally install the cmake for vcpkg
-COPY ./reinstall-cmake.sh /tmp/
-
-RUN if [ "${REINSTALL_CMAKE_VERSION_FROM_SOURCE}" != "none" ]; then \
-        chmod +x /tmp/reinstall-cmake.sh && /tmp/reinstall-cmake.sh ${REINSTALL_CMAKE_VERSION_FROM_SOURCE}; \
-    fi \
-    && rm -f /tmp/reinstall-cmake.sh
-
-RUN sudo apt-get update && sudo apt-get install uuid-dev faketime
-
-# [Optional] Uncomment this section to install additional vcpkg ports.
-# RUN su vscode -c "${VCPKG_ROOT}/vcpkg install <your-port-name-here>"
-
-# [Optional] Uncomment this section to install additional packages.
-# RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
-#     && apt-get -y install --no-install-recommends <your-package-list-here>

.devcontainer/devcontainer.json

@@ -1,24 +0,0 @@
-// For format details, see https://aka.ms/devcontainer.json. For config options, see the
-// README at: https://github.com/devcontainers/templates/tree/main/src/cpp
-{
-	"name": "Taskwarrior development environment",
-	"build": {
-		"dockerfile": "Dockerfile"
-	},
-	// Features to add to the dev container. More info: https://containers.dev/features.
-	"features": {
-		"ghcr.io/devcontainers/features/rust:1": {}
-	}
-
-	// Use 'forwardPorts' to make a list of ports inside the container available locally.
-	// "forwardPorts": [],
-
-	// Use 'postCreateCommand' to run commands after the container is created.
-	// "postCreateCommand": "gcc -v",
-
-	// Configure tool-specific properties.
-	// "customizations": {},
-
-	// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
-	// "remoteUser": "root"
-}

.devcontainer/reinstall-cmake.sh

@@ -1,59 +0,0 @@
-#!/usr/bin/env bash
-#-------------------------------------------------------------------------------------------------------------
-# Copyright (c) Microsoft Corporation. All rights reserved.
-# Licensed under the MIT License. See https://go.microsoft.com/fwlink/?linkid=2090316 for license information.
-#-------------------------------------------------------------------------------------------------------------
-#
-set -e
-
-CMAKE_VERSION=${1:-"none"}
-
-if [ "${CMAKE_VERSION}" = "none" ]; then
-    echo "No CMake version specified, skipping CMake reinstallation"
-    exit 0
-fi
-
-# Cleanup temporary directory and associated files when exiting the script.
-cleanup() {
-    EXIT_CODE=$?
-    set +e
-    if [[ -n "${TMP_DIR}" ]]; then
-        echo "Executing cleanup of tmp files"
-        rm -Rf "${TMP_DIR}"
-    fi
-    exit $EXIT_CODE
-}
-trap cleanup EXIT
-
-
-echo "Installing CMake..."
-apt-get -y purge --auto-remove cmake
-mkdir -p /opt/cmake
-
-architecture=$(dpkg --print-architecture)
-case "${architecture}" in
-    arm64)
-        ARCH=aarch64 ;;
-    amd64)
-        ARCH=x86_64 ;;
-    *)
-        echo "Unsupported architecture ${architecture}."
-        exit 1
-        ;;
-esac
-
-CMAKE_BINARY_NAME="cmake-${CMAKE_VERSION}-linux-${ARCH}.sh"
-CMAKE_CHECKSUM_NAME="cmake-${CMAKE_VERSION}-SHA-256.txt"
-TMP_DIR=$(mktemp -d -t cmake-XXXXXXXXXX)
-
-echo "${TMP_DIR}"
-cd "${TMP_DIR}"
-
-curl -sSL "https://github.com/Kitware/CMake/releases/download/v${CMAKE_VERSION}/${CMAKE_BINARY_NAME}" -O
-curl -sSL "https://github.com/Kitware/CMake/releases/download/v${CMAKE_VERSION}/${CMAKE_CHECKSUM_NAME}" -O
-
-sha256sum -c --ignore-missing "${CMAKE_CHECKSUM_NAME}"
-sh "${TMP_DIR}/${CMAKE_BINARY_NAME}" --prefix=/opt/cmake --skip-license
-
-ln -s /opt/cmake/bin/cmake /usr/local/bin/cmake
-ln -s /opt/cmake/bin/ctest /usr/local/bin/ctest

.git-blame-ignore-revs

@@ -1,2 +0,0 @@
-# initial bulk run of formatting with pre-commit
-93356b39c3086fdf8dd41d7357bb1c115ff69cb1

.gitea/workflows/release.yml

@@ -0,0 +1,16 @@
+on:
+  - push
+jobs:
+  ReleaseSrc:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repo
+        uses: actions/checkout@v4
+        with:
+          submodules: True
+      - name: Release Archive
+        uses: https://gitea.com/actions/gitea-release-action
+        with:
+          files: ./*
+          sha256sum: True
+

.github.bak/issue_template.md

@@ -9,4 +9,4 @@
 
 * Clearly describe the feature.
 * Clearly state the use case. We are only interested in use cases, do not waste time with implementation details or suggested syntax.
-* Please see our notes on [How to request a feature](https://taskwarrior.org/docs/features/)
+* Please see our notes on [How to request a feature](https://taskwarrior.org/docs/features.html)

.github.bak/pull_request_template.md

@@ -0,0 +1,9 @@
+#### Description
+
+Replace this text with a description of the PR.
+
+#### Additional information...
+
+- [ ] Have you run the test suite?
+  Many changes need to be tested. Please run the test suite
+  and include the output of ```cd test && ./problems```.

.github.bak/workflows/tests.yaml

@@ -0,0 +1,64 @@
+name: tests
+on: [push, pull_request]
+jobs:
+  tests:
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          - name: "Centos 8"
+            runner: ubuntu-latest
+            dockerfile: centos8
+          - name: "Fedora 32"
+            runner: ubuntu-latest
+            dockerfile: fedora32
+          - name: "Fedora 33"
+            runner: ubuntu-latest
+            dockerfile: fedora33
+          - name: "Fedora 34"
+            runner: ubuntu-latest
+            dockerfile: fedora34
+          - name: "Fedora 35"
+            runner: ubuntu-latest
+            dockerfile: fedora35
+          - name: "Debian Testing"
+            runner: ubuntu-latest
+            dockerfile: debiantesting
+          - name: "Ubuntu 18.04"
+            runner: ubuntu-latest
+            dockerfile: ubuntu1804
+          - name: "Ubuntu 20.04"
+            runner: ubuntu-latest
+            dockerfile: ubuntu2004
+          - name: "Ubuntu 21.04"
+            runner: ubuntu-latest
+            dockerfile: ubuntu2104
+          - name: "Ubuntu 21.10"
+            runner: ubuntu-latest
+            dockerfile: ubuntu2110
+          - name: "OpenSUSE 15"
+            runner: ubuntu-latest
+            dockerfile: opensuse15
+          - name: "Archlinux Base (Rolling)"
+            runner: ubuntu-latest
+            dockerfile: arch
+          - name: "Mac OS X 10.13"
+            runner: macos-latest
+            dockerfile: osx
+    runs-on: ${{ matrix.runner }}
+    continue-on-error: ${{ matrix.continue-on-error == true }}
+    steps:
+      - uses: actions/checkout@v2
+      - name: Build ${{ matrix.name }}
+        env:
+          DOCKER_REGISTRY: docker.pkg.github.com
+          DOCKER_CACHE_IMAGE: docker.pkg.github.com/${{ github.repository }}/taskwarrior_cache
+          GITHUB_USER: ${{ github.actor }}
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          CONTAINER: ${{ matrix.dockerfile }}
+        run: if [[ $CONTAINER != "osx" ]]; then docker-compose build test-$CONTAINER ; fi
+      - name: Test ${{ matrix.name }}
+        run: if [[ $CONTAINER != "osx" ]]; then docker-compose run test-$CONTAINER; else bash test/scripts/test_osx.sh ; fi
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          CONTAINER: ${{ matrix.dockerfile }}

.github/CONTRIBUTING.md

@@ -1 +0,0 @@
-Please see the ["Contributing to Taskwarrior"](https://github.com/GothenburgBitFactory/taskwarrior/tree/develop/doc/devel/contrib) section of the developer documentation.

.github/dependabot.yml

@@ -1,18 +0,0 @@
-version: 2
-updates:
-  # Enable version updates for GitHub actions
-  - package-ecosystem: "github-actions"
-    directory: "/"
-    schedule:
-      interval: "weekly"
-  # Enable updates for Rust packages
-  - package-ecosystem: "cargo"
-    directory: "/" # Location of package manifests
-    schedule:
-      interval: "daily"
-    ignore:
-      # skip patch updates, as they can be quite noisy, but keep
-      # minor and major updates so that we don't fall too far
-      # behind
-      - dependency-name: "*"
-        update-types: ["version-update:semver-patch"]

.github/workflows/checks.yml

@@ -1,82 +0,0 @@
-name: checks
-
-on:
-  push:
-    branches:
-      - develop
-  pull_request:
-    types: [opened, reopened, synchronize]
-
-jobs:
-  clippy:
-    runs-on: ubuntu-latest
-    name: "Check & Clippy"
-
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Cache cargo registry
-        uses: actions/cache@v4
-        with:
-          path: ~/.cargo/registry
-          key: ${{ runner.os }}-cargo-registry-${{ hashFiles('**/Cargo.lock') }}
-
-      - name: Cache cargo build
-        uses: actions/cache@v4
-        with:
-          path: target
-          key: ${{ runner.os }}-cargo-build-target-${{ hashFiles('**/Cargo.lock') }}
-
-      - uses: actions-rs/toolchain@v1
-        with:
-          # If this version is old enough to cause errors, or older than the
-          # TaskChampion MSRV, bump it to the MSRV of the currently-required
-          # TaskChampion package; if necessary, bump that version as well.
-          toolchain: "1.81.0" # MSRV
-          override: true
-
-      - uses: actions-rs/cargo@v1.0.3
-        with:
-          command: check
-
-      - run: rustup component add clippy
-
-      - uses: actions-rs/clippy-check@v1
-        with:
-          token: ${{ secrets.GITHUB_TOKEN }}
-          args: --all-features
-          name: "Clippy Results"
-
-  fmt:
-    runs-on: ubuntu-latest
-    name: "Formatting"
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions-rs/toolchain@v1
-        with:
-          profile: minimal
-          components: rustfmt
-          toolchain: stable
-          override: true
-
-      - uses: actions-rs/cargo@v1.0.3
-        with:
-          command: fmt
-          args: --all -- --check
-
-  cargo-metadata:
-    runs-on: ubuntu-latest
-    name: "Cargo Metadata"
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions-rs/toolchain@v1
-        with:
-          profile: minimal
-          components: rustfmt
-          toolchain: stable
-          override: true
-
-      - name: "Check metadata"
-        run: ".github/workflows/metadata-check.sh"

.github/workflows/docker-image.yaml

@@ -1,57 +0,0 @@
-name: Taskwarrior Docker image
-
-on:
-  workflow_dispatch:
-  workflow_run:
-    workflows: [tests]
-    branches:
-      - develop
-      - stable
-    types:
-      - completed
-
-env:
-  REGISTRY: "ghcr.io"
-
-jobs:
-  build-and-push-docker-image:
-    runs-on: ubuntu-latest
-    if: ${{ github.event.workflow_run.conclusion == 'success' }}
-    permissions:
-      contents: read
-      packages: write
-      id-token: write
-
-    steps:
-      - name: Create lowercase repository name
-        run: |
-          GHCR_REPOSITORY="${{ github.repository_owner }}"
-          echo "REPOSITORY=${GHCR_REPOSITORY,,}" >> ${GITHUB_ENV}
-      - name: Checkout repository
-        uses: actions/checkout@v4
-        with:
-          submodules: "recursive"
-
-      - name: Install cosign
-        uses: sigstore/cosign-installer@v3.7.0
-
-      - name: Log into registry ${{ env.REGISTRY }}
-        uses: docker/login-action@v3.3.0
-        with:
-          registry: ${{ env.REGISTRY }}
-          username: ${{ github.repository_owner }}
-          password: ${{ secrets.GITHUB_TOKEN }}
-
-      - name: Build and push Taskwarrior Docker image
-        id: build-and-push
-        uses: docker/build-push-action@v6.10.0
-        with:
-          context: .
-          file: "./docker/task.dockerfile"
-          push: true
-          tags: ${{ env.REGISTRY }}/${{ env.REPOSITORY }}/task:${{ github.ref_name }}
-
-      - name: Sign the published Docker image
-        env:
-          COSIGN_EXPERIMENTAL: "true"
-        run: cosign sign ${{ env.REGISTRY }}/${{ env.REPOSITORY }}/task@${{ steps.build-and-push.outputs.digest }}

.github/workflows/metadata-check.sh

@@ -1,32 +0,0 @@
-#! /bin/bash
-
-# Check the 'cargo metadata' for various requirements
-
-set -e
-
-META=$(mktemp)
-trap 'rm -rf -- "${META}"' EXIT
-
-cargo metadata --locked --format-version 1 > "${META}"
-
-get_msrv() {
-  local package="${1}"
-  jq -r '.packages[] | select(.name == "'"${package}"'") | .rust_version' "${META}"
-}
-
-check_msrv() {
-  local taskchampion_msrv=$(get_msrv taskchampion)
-  local taskchampion_lib_msrv=$(get_msrv taskchampion-lib)
-
-  echo "Found taskchampion MSRV ${taskchampion_msrv}"
-  echo "Found taskchampion-lib MSRV ${taskchampion_lib_msrv}"
-
-  if [ "${taskchampion_msrv}" != "${taskchampion_lib_msrv}" ]; then
-    echo "Those MSRVs should be the same (or taskchampion-lib should be greater, in which case adjust this script)"
-    exit 1
-  else
-    echo "✓ MSRVs are at the same version."
-  fi
-}
-
-check_msrv

.github/workflows/release-check.yaml

@@ -1,30 +0,0 @@
-name: release-tests
-on: [push, pull_request]
-jobs:
-  check-tarball:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Cache cargo registry
-        uses: actions/cache@v4
-        with:
-          path: ~/.cargo/registry
-          key: ${{ runner.os }}-cargo-registry-${{ hashFiles('**/Cargo.lock') }}
-
-      - uses: actions-rs/toolchain@v1
-        with:
-          toolchain: "stable"
-          override: true
-
-      - name: Install uuid-dev
-        run: sudo apt install uuid-dev
-
-      - name: make a release tarball and build from it
-        run: |
-          cmake -S. -Bbuild &&
-          make -Cbuild package_source &&
-          tar -xf build/task-*.tar.gz &&
-          cd task-*.*.* &&
-          cmake -S. -Bbuild &&
-          cmake --build build --target task_executable

.github/workflows/security.yml

@@ -1,20 +0,0 @@
-name: security
-
-on:
-  schedule:
-    - cron: '0 0 * * *'
-  push:
-    paths:
-      - '**/Cargo.toml'
-      - '**/Cargo.lock'
-
-jobs:
-  audit:
-    runs-on: ubuntu-latest
-    permissions: write-all
-    name: "Audit Rust Dependencies"
-    steps:
-      - uses: actions/checkout@v4
-      - uses: rustsec/audit-check@master
-        with:
-          token: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/tests.yaml

@@ -1,174 +0,0 @@
-## Run the Taskwarrior tests, using stable rust to build TaskChampion.
-name: tests
-
-on: [push, pull_request]
-
-jobs:
-  coverage:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Install apt packages
-        run: sudo apt-get install -y build-essential cmake git uuid-dev faketime locales python3 curl gcovr ninja-build
-
-      - name: Check out this repository
-        uses: actions/checkout@v4.1.6
-
-      - name: Configure project
-        run: cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS=--coverage
-
-      - name: Build project
-        run: cmake --build build --target test_runner --target task_executable
-
-      - name: Test project
-        run: ctest --test-dir build -j 8 --output-on-failure
-
-      - name: Generate a code coverage report
-        uses: threeal/gcovr-action@v1.1.0
-        with:
-          coveralls-out: coverage.coveralls.json
-          excludes: |
-            build
-
-      - name: Sent to Coveralls
-        uses: coverallsapp/github-action@v2
-        with:
-          file: coverage.coveralls.json
-
-  # MacOS tests do not run in Docker, and use the actions-rs Rust installaction
-  tests-macos-12:
-    needs: coverage
-    name: tests (Mac OS 12.latest)
-    if: false # see #3242
-    runs-on: macos-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Cache cargo registry
-        uses: actions/cache@v4
-        with:
-          path: ~/.cargo/registry
-          key: ${{ runner.os }}-stable-cargo-registry-${{ hashFiles('**/Cargo.lock') }}
-
-      - name: Cache cargo build
-        uses: actions/cache@v4
-        with:
-          path: target
-          key: ${{ runner.os }}-stable-cargo-build-target-${{ hashFiles('**/Cargo.lock') }}
-
-      - uses: actions-rs/toolchain@v1
-        with:
-          toolchain: "stable"
-          override: true
-
-      - name: Test MacOS
-        run: bash test/scripts/test_macos.sh
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-  tests-macos-13:
-    needs: coverage
-    name: tests (Mac OS 13.latest)
-    if: false # see #3242
-    runs-on: macos-13
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Cache cargo registry
-        uses: actions/cache@v4
-        with:
-          path: ~/.cargo/registry
-          key: ${{ runner.os }}-stable-cargo-registry-${{ hashFiles('**/Cargo.lock') }}
-
-      - name: Cache cargo build
-        uses: actions/cache@v4
-        with:
-          path: target
-          key: ${{ runner.os }}-stable-cargo-build-target-${{ hashFiles('**/Cargo.lock') }}
-
-      - uses: actions-rs/toolchain@v1
-        with:
-          toolchain: "stable"
-          override: true
-
-      - name: Test MacOS
-        run: bash test/scripts/test_macos.sh
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-
-  cargo-test:
-    runs-on: ubuntu-latest
-    name: "Cargo Test"
-
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Cache cargo registry
-        uses: actions/cache@v4
-        with:
-          path: ~/.cargo/registry
-          key: ${{ runner.os }}-cargo-registry-${{ hashFiles('**/Cargo.lock') }}
-
-      - name: Cache cargo build
-        uses: actions/cache@v4
-        with:
-          path: target
-          key: ${{ runner.os }}-cargo-build-target-${{ hashFiles('**/Cargo.lock') }}
-
-      - uses: actions-rs/toolchain@v1
-        with:
-          # If this version is old enough to cause errors, or older than the
-          # TaskChampion MSRV, bump it to the MSRV of the currently-required
-          # TaskChampion package; if necessary, bump that version as well.
-          # This should match the MSRV in `src/taskchampion-cpp/Cargo.toml`.
-          toolchain: "1.81.0" # MSRV
-          override: true
-
-      - uses: actions-rs/cargo@v1.0.3
-        with:
-          command: test
-
-  tests:
-    needs: coverage
-    strategy:
-      fail-fast: false
-      matrix:
-        include:
-          - name: "Fedora 40"
-            runner: ubuntu-latest
-            dockerfile: fedora40
-          - name: "Fedora 41"
-            runner: ubuntu-latest
-            dockerfile: fedora41
-          - name: "Debian Testing"
-            runner: ubuntu-latest
-            dockerfile: debiantesting
-          - name: "Ubuntu 20.04"
-            runner: ubuntu-latest
-            dockerfile: ubuntu2004
-          - name: "Ubuntu 22.04"
-            runner: ubuntu-latest
-            dockerfile: ubuntu2204
-          - name: "OpenSUSE Tumbleweed (Rolling)"
-            runner: ubuntu-latest
-            dockerfile: opensuse
-          - name: "Archlinux Base (Rolling)"
-            runner: ubuntu-latest
-            dockerfile: arch
-    runs-on: ${{ matrix.runner }}
-    continue-on-error: ${{ matrix.continue-on-error == true }}
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Build ${{ matrix.name }}
-        env:
-          DOCKER_REGISTRY: docker.pkg.github.com
-          DOCKER_CACHE_IMAGE: docker.pkg.github.com/${{ github.repository }}/taskwarrior_cache
-          GITHUB_USER: ${{ github.actor }}
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          CONTAINER: ${{ matrix.dockerfile }}
-        run: docker compose build test-${{ env.CONTAINER }}
-
-      - name: Test ${{ matrix.name }}
-        run: docker compose run test-${{ env.CONTAINER }}
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          CONTAINER: ${{ matrix.dockerfile }}

.gitignore

@@ -1,13 +1,22 @@
 cmake.h
 commit.h
-.cache
+Makefile
+src/task
+src/taskd
+src/libtask.a
+src/commands/libcommands.a
+src/columns/libcolumns.a
 *~
 .*.swp
-Session.vim
 package-config/osx/binary/task
-/*build*/
+CMakeFiles
+CMakeCache.txt
+cmake_install.cmake
+install_manifest.txt
+_CPack_Packages
+CPackConfig.cmake
+CPackSourceConfig.cmake
 patches
+*.exe
 tutorials
 .prove
-/target/
-/.idea/

.gitmodules

@@ -1,6 +1,3 @@
 [submodule "src/libshared"]
 	path = src/libshared
 	url = https://github.com/GothenburgBitFactory/libshared.git
-[submodule "src/taskchampion-cpp/corrosion"]
-	path = src/taskchampion-cpp/corrosion
-	url = https://github.com/corrosion-rs/corrosion.git

.pre-commit-config.yaml

@@ -1,19 +0,0 @@
-# See https://pre-commit.com for more information
-# See https://pre-commit.com/hooks.html for more hooks
-repos:
-- repo: https://github.com/pre-commit/pre-commit-hooks
-  rev: v5.0.0
-  hooks:
-  - id: trailing-whitespace
-  - id: end-of-file-fixer
-  - id: check-yaml
-  - id: check-added-large-files
-- repo: https://github.com/pre-commit/mirrors-clang-format
-  rev: v19.1.6
-  hooks:
-  - id: clang-format
-    types_or: [c++, c]
-- repo: https://github.com/psf/black
-  rev: 24.10.0
-  hooks:
-  - id: black

CMakeLists.txt

@@ -1,23 +1,16 @@
-cmake_minimum_required (VERSION 3.22)
-enable_testing()
-
-set (CMAKE_EXPORT_COMPILE_COMMANDS ON)
-
-project (task
-  VERSION 3.3.0
-  DESCRIPTION "Taskwarrior - a command-line TODO list manager"
-  HOMEPAGE_URL https://taskwarrior.org/)
-
+cmake_minimum_required (VERSION 3.5)
 set (CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake")
 
-include (FetchContent)
 include (CheckFunctionExists)
 include (CheckStructHasMember)
 
 set (HAVE_CMAKE true)
 
+project (task)
 include (CXXSniffer)
 
+set (PROJECT_VERSION "2.6.2")
+
 OPTION (ENABLE_WASM "Enable 'wasm' support" OFF)
 
 if (ENABLE_WASM)
@@ -25,19 +18,28 @@ if (ENABLE_WASM)
   set(CMAKE_EXECUTABLE_SUFFIX ".js")
 endif (ENABLE_WASM)
 
-message ("-- Looking for git submodules")
-if (EXISTS ${CMAKE_SOURCE_DIR}/src/libshared/src AND EXISTS ${CMAKE_SOURCE_DIR}/src/taskchampion-cpp/corrosion)
-  message ("-- Found git submodules")
+OPTION (ENABLE_SYNC "Enable 'task sync' support" ON)
+
+if (ENABLE_SYNC)
+  set (USE_GNUTLS ON CACHE BOOL "Build gnutls support." FORCE)
+else (ENABLE_SYNC)
+  set (USE_GNUTLS OFF CACHE BOOL "Build gnutls support." FORCE)
+  message (WARNING "ENABLE_SYNC=OFF. Not building sync support.")
+endif (ENABLE_SYNC)
+
+message ("-- Looking for libshared")
+if (EXISTS ${CMAKE_SOURCE_DIR}/src/libshared/src)
+  message ("-- Found libshared")
 else (EXISTS ${CMAKE_SOURCE_DIR}/src/libshared/src)
-  message ("-- Cloning git submodules")
+  message ("-- Cloning libshared")
   execute_process (COMMAND git submodule update --init
                    WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
-endif (EXISTS ${CMAKE_SOURCE_DIR}/src/libshared/src AND EXISTS ${CMAKE_SOURCE_DIR}/src/taskchampion-cpp/corrosion)
+endif (EXISTS ${CMAKE_SOURCE_DIR}/src/libshared/src)
 
 message ("-- Looking for SHA1 references")
 if (EXISTS ${CMAKE_SOURCE_DIR}/.git/index)
   set (HAVE_COMMIT true)
-  execute_process (COMMAND git log -1 --pretty=format:%h --no-show-signature
+  execute_process (COMMAND git log -1 --pretty=format:%h
                    WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
                    OUTPUT_VARIABLE COMMIT)
   configure_file ( ${CMAKE_SOURCE_DIR}/commit.h.in
@@ -64,8 +66,19 @@ SET (TASK_DOCDIR  share/doc/task CACHE STRING "Installation directory for doc fi
 SET (TASK_RCDIR "${TASK_DOCDIR}/rc" CACHE STRING "Installation directory for configuration files")
 SET (TASK_BINDIR  bin            CACHE STRING "Installation directory for the binary")
 
-# rust libs require these
-set (TASK_LIBRARIES dl pthread)
+if (USE_GNUTLS)
+   message ("-- Looking for GnuTLS")
+   find_package (GnuTLS)
+   if (GNUTLS_FOUND)
+     set (HAVE_LIBGNUTLS true)
+     set (TASK_INCLUDE_DIRS ${TASK_INCLUDE_DIRS} ${GNUTLS_INCLUDE_DIR})
+     set (TASK_LIBRARIES    ${TASK_LIBRARIES}    ${GNUTLS_LIBRARIES})
+   endif (GNUTLS_FOUND)
+endif (USE_GNUTLS)
+
+if (ENABLE_SYNC AND NOT GNUTLS_FOUND)
+  message (FATAL_ERROR "Cannot find GnuTLS. Use -DENABLE_SYNC=OFF to build Taskwarrior without sync support. See INSTALL for more information.")
+endif (ENABLE_SYNC AND NOT GNUTLS_FOUND)
 
 check_function_exists (timegm  HAVE_TIMEGM)
 check_function_exists (get_current_dir_name HAVE_GET_CURRENT_DIR_NAME)
@@ -130,11 +143,6 @@ if (SOLARIS)
   endif (NSL_LIBRARY)
 endif (SOLARIS)
 
-# Disable the Clang return-type-c-linkage warning globally. See #3225.
-if (CMAKE_CXX_COMPILER_ID STREQUAL "Clang" OR CMAKE_CXX_COMPILER_ID STREQUAL "AppleClang")
-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-return-type-c-linkage")
-endif (CMAKE_CXX_COMPILER_ID STREQUAL "Clang" OR CMAKE_CXX_COMPILER_ID STREQUAL "AppleClang")
-
 message ("-- Configuring cmake.h")
 configure_file (
   ${CMAKE_SOURCE_DIR}/cmake.h.in
@@ -142,26 +150,42 @@ configure_file (
 
 add_subdirectory (src)
 add_subdirectory (src/commands)
-add_subdirectory (src/taskchampion-cpp)
 add_subdirectory (src/columns)
 add_subdirectory (doc)
 add_subdirectory (scripts)
 if (EXISTS ${CMAKE_SOURCE_DIR}/test)
   add_subdirectory (test EXCLUDE_FROM_ALL)
 endif (EXISTS ${CMAKE_SOURCE_DIR}/test)
-if (EXISTS ${CMAKE_SOURCE_DIR}/performance)
+if (EXISTS performance)
   add_subdirectory (performance EXCLUDE_FROM_ALL)
-endif (EXISTS ${CMAKE_SOURCE_DIR}/performance)
+endif (EXISTS performance)
 
-set (doc_FILES ChangeLog README.md INSTALL AUTHORS COPYING LICENSE)
+set (doc_FILES NEWS ChangeLog README.md INSTALL AUTHORS COPYING LICENSE)
 foreach (doc_FILE ${doc_FILES})
   install (FILES ${doc_FILE}  DESTINATION ${TASK_DOCDIR})
 endforeach (doc_FILE)
 
+add_custom_command(OUTPUT run-review
+    COMMAND docker build -q --build-arg PR=$(PR) --build-arg LIBPR=$(LIBPR) -t taskwarrior-review:$(PR)s$(LIBPR) - < scripts/review-dockerfile
+    COMMAND docker run --rm --memory 1g --hostname pr-$(PR)s$(LIBPR) -it taskwarrior-review:$(PR)s$(LIBPR) bash || :
+)
+add_custom_target(review DEPENDS run-review)
+
+add_custom_command(OUTPUT run-reproduce
+    COMMAND docker build -q --build-arg RELEASE=$(RELEASE) -t taskwarrior-reproduce:$(RELEASE) - < scripts/reproduce-dockerfile
+    COMMAND docker run --rm --memory 1g --hostname tw-$(RELEASE) -it taskwarrior-reproduce:$(RELEASE) bash || :
+)
+add_custom_target(reproduce DEPENDS run-reproduce)
+
 # ---
 
 set (CPACK_SOURCE_GENERATOR "TGZ")
 set (CPACK_SOURCE_PACKAGE_FILE_NAME ${PACKAGE_NAME}-${PACKAGE_VERSION})
-set (CPACK_SOURCE_IGNORE_FILES  "build" "test" "misc/*" "performance" "swp$" "src/lex$" "task-.*.tar.gz"
-                                "commit.h" "cmake.h$" "\\\\.gitmodules" "src/libshared/\\\\.git" ".github/" ".*\\\\.gitignore$" "docker-compose.yml" "\\\\.git/")
+set (CPACK_SOURCE_IGNORE_FILES  "CMakeCache" "CMakeFiles" "CPackConfig" "CPackSourceConfig"
+                                "_CPack_Packages" "cmake_install" "install_manifest" "Makefile$"
+                                "test" "package-config" "misc/*" "src/task$" "src/calc$" "performance"
+                                "src/libtask.a" "src/columns/libcolumns.a" "src/commands/libcommands.a"
+                                "swp$" "src/lex$" "task-.*.tar.gz" "commit.h" "cmake.h$" "\\\\.gitmodules"
+                                "src/libshared/\\\\.git" ".github/" ".*\\\\.gitignore$"
+                                "src/liblibshared.a" "docker-compose.yml" "\\\\.git/")
 include (CPack)

Cargo.toml

@@ -1,7 +0,0 @@
-[workspace]
-
-members = [
-    "src/taskchampion-cpp",
-]
-
-resolver = "2"

ChangeLog

@@ -1,152 +1,4 @@
 ------ current release ---------------------------
-
-- Sync now supports AWS S3 as a backend.
-- A new `task import-v2` command allows importing Taskwarrior-2.x
-  data files directly.
-
-3.3.0 -
-
-Thanks to the following people for contributions to this release:
-
- - Chongyun Lee
- - David Tolnay
- - Dustin J. Mitchell
- - Felix Schurk
- - geoffpaulsen
- - Kalle Kietäväinen
- - Kursat Aktas
- - Scott Mcdermott
- - Thomas Lauf
-
------- old releases ------------------------------
-
-3.2.0 -
-
- - Support for the journal in `task info` has been restored (#3671) and the
-   task info output no longer contains `tag_` values (#3619).
- - The `rc.weekstart` value now affects calculation of week numbers in
-   expressions like `2013-W49` (#3654).
- - Build-time flag `ENABLE_TLS_NATIVE_ROOTS` will cause `task sync` to use the
-   system TLS roots instead of its built-in roots to authenticate the server (#3660).
- - The output from `task undo` is now more human-readable. The `undo.style`
-   configuraiton option, which has had no effect since 3.0.0, is now removed (3672).
- - Fetching pending tasks is now more efficient (#3661).
-
-Thanks to the following people for contributions to this release:
-
- - Denis Zh.
- - Dustin J. Mitchell
- - Fredrik Lanker
- - Gagan Nagaraj
- - Jan Christian Grünhage
- - Scott Mcdermott
- - Thomas Lauf
- - Tobias Predel
-
-3.1.0 -
-
- - Support for `task purge` has been restored, and new support added for automatically
-   expiring old tasks. (#3540, #3546, #3556)
- - `task news` is now better behaved, and can be completely disabled.
- - Multiple imports of the same UUID will now generate a warning. (#3560)
- - The `sync.server.url` config replaces `sync.server.origin` and allows a URL
-   containing a path. (#3423)
- - The new `bubblegum-256.theme` has improved legibility and contrast over
-   others. (#3505)
- - Warnings regarding `.data` files are only show for reports. (#3473)
- - Inherited urgency is correctly calculated to make parents more urgent than
-   children (#2941)
- - Task completion commands no longer trigger hooks (#3133)
-
-Thanks to the following people for contributions to this release:
-
- - Adrian Galilea
- - Adrian Sadłocha
- - Andonome
- - Christian Clauss
- - Dominik Rehák
- - Dustin J. Mitchell
- - Felix Schurk
- - Hector Dearman
- - Joseph Coffa
- - koleesch
- - Maarten Aertsen
- - mattsmida
- - Philipp Oberdiek
- - Sebastian Carlos
- - sleepy_nols
- - Steve Dondley
- - Will R S Hansen
-
-3.0.2 -
-
-- Fix an accidentally-included debug print which polluted output of
-  reports with the Taskwarrior version (#3389)
-
-3.0.1 -
-
-- Fix an error in creation of the 3.0.0 tarball which caused builds to fail (#3302)
-- Improvements to `task news`, including notes for the 3.0.0 release
-- Minor improvements to documentation and error handling
-- Fix incorrect task ID of 0 when using hooks (#3339)
-- Issue a warning if .data files remain (#3321)
-
-3.0.0 -
-
-- [BREAKING CHANGE] the sync functionality has been rewritten entirely, and
-  no longer supports taskserver/taskd. Instead, the recommended solution is
-  a cloud-storage backend, although `taskchampion-sync-server` is also
-  available.
-
-  See https://taskwarrior.org/docs/upgrade-3/ for information on upgrading to
-  Taskwarrior 3.0.
-
-  The following config options are no longer supported:
-  - `debug.tls`
-  - `taskd.ca`
-  - `taskd.certificate`
-  - `taskd.ciphers`
-  - `taskd.credentials`
-  - `taskd.key`
-  - `taskd.server`
-  - `taskd.trust`
-
-  The Taskwarrior build no longer requires GnuTLS. The build option
-  `ENABLE_SYNC=OFF` is also no longer supported; sync support is always built
-  in.
-
-  Deep thanks to the following for contributions to this work:
-
-  - Akash Shanmugaraj
-  - Andrew Savchenko
-  - Dathan Bennett
-  - Dustin Mitchell
-  - dbr/Ben
-  - Felix Schurk
-  - Isaac Wyatt
-  - Nathan Luong
-  - Nikos Koukis
-  - Pablo Baeyens
-  - Ravi Sawlani
-  - ryneeverett
-  - Simon Fraser
-
-- TW #2732 Fix urgency inheritance for negative-urgency tasks.
-          Thanks to Jackson Abascal for contributing.
-- TW #2763 `task show` now shows `hooks.location.
-           Thanks to rollniak for reporting and sec65 for contributing.
-- TW #2765 Fix leading space before urgency value in `task info`.
-           Thanks to Dominik Rehák for contributing.
-- TW #2780 Fix formatting of countdown-style dates
-           Thanks to Dominik Rehák for contributing.
-- TW #2826 Fix issue with filter not applied correctly during `task _tags` command
-           Thanks to Nikos Koukis for contributing.
-- TW #3052 Parsing of timestamp values now uses 64-bit integers, avoiding
-           issues in the year 2032.
-           Thanks to Bernhard M. Wiedemann for contributing.
-- TW #3068 Fix fish completion.
-           Thanks to Michal Koutný for contributing.
-
 2.6.2 -
 
 - TW #502  Sequence of IDs doesn't work with attribute "depends"
@@ -323,6 +175,8 @@ Thanks to the following people for contributions to this release:
            Thanks to bharatvaj for contributing.
 - TW #2581 Config entry with a trailing comment cannot be modified
 
+------ old releases ------------------------------
+
 2.5.3 (2021-01-05) - 2f47226f91f0b02f7617912175274d9eed85924f
 
 - #2375   task hangs then dies when certain tasks are present in a report
@@ -2860,3 +2714,4 @@ regular usage to determine which features were needed or unnecessary.]
 - Usage.
 
 ------ start -----------------------------------
+

DEVELOPER.md

@@ -1 +1,146 @@
-See [Developing Taskwarrior](./doc/devel/contrib/README.md).
+# How to Build Taskwarrior
+
+## Satisfy the Requirements:
+ * CMake 3.0 or later
+ * gcc 7.0 or later, clang 6.0 or later, or a compiler with full C++17 support
+ * libuuid (if not on macOS)
+ * gnutls (optional)
+ * python 3 (optional, for running the test suite)
+
+## Obtain and build code:
+```
+    $ git clone --recursive https://github.com/GothenburgBitFactory/taskwarrior taskwarrior.git
+    $ cd taskwarrior.git
+    $ git checkout develop               # Latest dev branch
+    $ git submodule init                 # This is now done by cmake as a test
+    $ git submodule update               # Update the libhsared.git submodule
+    $ cmake -DCMAKE_BUILD_TYPE=debug .   # debug or release. Default: neither
+    $ make VERBOSE=1 -j4                 # Shows details, builds using 4 jobs
+                                         # Alternately 'export MAKEFLAGS=-j 4'
+```
+## Running Test Suite:
+```
+    $ cd test
+    $ make VERBOSE=1                     # Shows details
+    $ ./run_all                          # Runs all tests silently > all.log
+    $ ./problems                         # Enumerate test failures in all.log
+```
+
+  Note that any development should be performed using a git clone, and the
+  current development branch. The source tarballs do not reflect HEAD, and do
+  not contain the test suite.
+
+  If you send a patch (support@gothenburgbitfactory.org), make sure that patch is made
+  against git HEAD on the development branch. We cannot apply patches made
+  against the tarball source, or master.
+
+
+# General Statement
+  This file is intended to convey the current efforts, priorities and needs of
+  the code base. It is for anyone looking for a way to start contributing.
+  Here are many ways to contribute that may not be obvious:
+
+  * Use Taskwarrior, become familiar with it, and make suggestions. There are
+    always ongoing discussions about new features and changes to existing
+    features.
+
+  * Join us in the #taskwarrior IRC channel on freenode.net or libera.chat.
+    Many great ideas, suggestions, testing and discussions have taken place
+    there. It is also the quickest way to get help, or confirm a bug.
+
+  * Review documentation: there are man pages, online articles, tutorials and
+    so on, and these may contain errors, or they may not convey ideas in the
+    best way. Perhaps you can help improve it. Contact us - documentation is
+    a separate effort from the code base, and includes all web sites, and all
+    are available as git repositories.
+
+  * Take a look at the bug database, and help triage the bug list. This is a
+    review process that involves confirming bugs, providing additional data,
+    information or analysis. Bug triage is very useful and much needed. You
+    could check to see that an old bug is still relevant - sometimes they are
+    not.
+
+  * Review the source code, and point out inefficiencies, problems, unreadable
+    functions, bugs and assumptions.
+
+  * Fix a bug. For this you'll need C++ and Git skills. We welcome all bug
+    fixes, provided the work is done well and doesn't create other problems or
+    introduce new dependencies. We recommend talking to us before starting.
+    Seriously.
+
+  * Add unit tests. Unit tests are possibly the most useful contributions of
+    all, because they not only improve the quality of the code, but prevent
+    future regressions, therefore maintaining quality of subsequent releases.
+    Plus, broken tests are a great motivator for us to fix the causal defect.
+    You'll need Python skills.
+
+  * Add a feature. Well, let's be very clear about this: adding a feature is
+    not usually well-received, and if you add a feature and send a patch, it
+    will most likely be rejected. The reason for this is that there are many
+    efforts under way, in various code branches. There is a very good chance
+    that the feature you add is either already in progress, or being done in a
+    way that is more fitting when considering other work in progress. So if
+    you want to add a feature, please don't. Start by talking to us, and find
+    out what is currently under way or planned. You might find that we've
+    already rejected such a feature for some very good reasons. So please
+    check first, so we don't duplicate effort or waste anyone's time.
+
+  * Spread the word. Help others become more effective at managing tasks.
+
+  * Encouragement. Tell us what works for you, and what doesn't. Tell us about
+    your methodology for managing tasks. It's all useful information.
+
+  * Request a feature. This not only tells us that you think something is
+    missing from the software, but gives us insights into how you use it.
+    Plus, you might get your feature implemented.
+
+# Unit Tests Needed
+  There are always more unit tests needed. More specifically, better unit tests
+  are always needed. The convention is that there are four types of unit test:
+
+  1. High level tests that exercise large features, or combinations of commands.
+     For example, dependencies.t runs through a long list of commands that test
+     dependencies, but do so by using 'add', 'modify', 'done' and 'delete'.
+  1. Regression tests that ensure certain bugs are fixed and stay fixed. These
+     tests are named tw-NNNN.t where NNNN refers to the bug number. While it is
+     not worth creating tests for small fixes like typos, it is for logic
+     changes.
+  1. Small feature tests. When small features are added, we would like small,
+     low-level feature tests named feature.t, with a descriptive name and
+     focused tests.
+  1. Code tests. These are tests written in C++ that exercise C++ objects, or
+     function calls. These are the lowest level tests. It is important that
+     these kind of tests be extensive and thorough, because the software depends
+     on this code the most.
+
+  The tests are written in Python, Bash and C++, and all use TAP.
+
+## Tests needed
+
+  * Take a look at the bug database (https://github.com/GothenburgBitFactory/taskwarrior/issues)
+    and notice that many issues, open and closed, have the "needsTest" label.
+    These are things that we would like to see in the test suite, as regression
+    tests.
+
+  All new unit tests should follow the test/template.t standard.
+
+# Patches
+  Patches are encouraged and welcomed. Either send a pull request on Github or
+  email a patch to support@taskwarrior.org. A good patch:
+
+    * Maintains the MIT license, and does not contain code lifted from other
+      sources. You will have written 100% of the code in the patch, otherwise
+      we cannot maintain the license.
+    * Precisely addresses one issue only.
+    * Doesn't break unit tests. This means yes, run the unit tests.
+    * Doesn't introduce dependencies.
+    * Is accompanied by new or updated unit tests, where appropriate.
+    * Is accompanied by documentation changes, where appropriate.
+    * Conforms to the prevailing coding standards - in other words, it should
+      fit in with the existing code.
+
+  A patch may be rejected for violating any of the above rules, and more.
+  Bad patches may be accepted and modified depending on work load and mood. It
+  is possible that a patch may be rejected because it conflicts in some way with
+  plans or upcoming changes. Check with us first, before sinking time and effort
+  into a patch.

INSTALL

@@ -20,21 +20,20 @@ You will need a C++ compiler that supports full C++17, which includes:
 
 You will need the following libraries:
   - libuuid (not needed for OSX)
+  - gnutls  (can be optional - see '"sync" command' below)
 
-You will need a Rust toolchain of the Minimum Supported Rust Version (MSRV):
-  - rust 1.81.0
 
 Basic Installation
 ------------------
 
 Briefly, these shell commands will unpack, build and install Taskwarrior:
 
-  $ tar xzf task-X.Y.Z.tar.gz                        [1]
-  $ cd task-X.Y.Z                                    [2]
-  $ cmake -S . -B build -DCMAKE_BUILD_TYPE=Release . [3]
-  $ cmake --build build                              [4]
-  $ sudo cmake --install build                       [5]
-  $ cd .. ; rm -r task-X.Y.Z                         [6]
+  $ tar xzf task-X.Y.Z.tar.gz                   [1]
+  $ cd task-X.Y.Z                               [2]
+  $ cmake -DCMAKE_BUILD_TYPE=release .          [3]
+  $ make                                        [4]
+  $ sudo make install                           [5]
+  $ cd .. ; rm -r task-X.Y.Z                    [6]
 
 These commands are explained below:
 
@@ -89,10 +88,19 @@ get absolute installation directories:
   CMAKE_INSTALL_PREFIX/TASK_MAN1DIR  /usr/local/share/man/man1
   CMAKE_INSTALL_PREFIX/TASK_MAN5DIR  /usr/local/share/man/man5
 
-The following variables control aspects of the build process:
 
-  SYSTEM_CORROSION - Use system provided corrosion instead of vendored version
-  ENABLE_TLS_NATIVE_ROOTS - Use the system's TLS root certificates
+"sync" command
+--------------
+
+By default, GnuTLS support is required, which enables the "sync" command.
+For Debian based distributions, installing "libgnutls-dev" is sufficient.
+
+In order to build Taskwarrior without "sync" support, call cmake with the
+"-DENABLE_SYNC=OFF" flag:
+
+   $ cmake . -DENABLE_SYNC=OFF
+
+and proceed as described in "Basic Installation".
 
 
 Uninstallation
@@ -115,43 +123,6 @@ If Taskwarrior will not build on your system, first take a look at the Operating
 System notes below.  If this doesn't help, then go to the Troubleshooting
 section, which includes instructions on how to contact us for help.
 
-Offline Build Notes
--------------------
-
-It is common for packaging systems (e.g. NixOS, FreeBSD Ports Collection, pkgsrc, etc)
-to disable networking during builds.  This restriction requires all distribution files
-to be prepositioned after checksum verification as a prerequisite for the build.  The
-following steps have been successful in allowing Taskwarrior to be built in this
-environment:
-
-1. Extract all crates in a known location, e.g. ${WRKDIR}/cargo-crates
-This includes crates needed for corrosion (search for Cargo.lock files)
-
-2. Create .cargo-checksum.json for each crate
-For example:
-printf '{"package":"%s","files":{}}' $(sha256 -q ${DISTDIR}/rayon-core-1.12.1.tar.gz) \
-        > ${WRKDIR}/cargo-crates/rayon-core-1.12.1/.cargo-checksum.json
-
-3. Create a custom config.toml file
-For example, ${WRKDIR}/.cargo/config.toml
-[source.cargo]
-directory = '${WRKDIR}/cargo-crates'
-[source.crates-io]
-replace-with = 'cargo'
-
-4. After running cmake, configure cargo
-For example:
-cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${CARGO_ENV} \
-  /usr/local/bin/cargo update \
-  --manifest-path ${WRKDIR}/.cargo/config.toml \
-  --verbose
-
-5. Set CARGO_HOME in environment
-For example
-CARGO_HOME=${WRKDIR}/.cargo
-
-The build and installation steps should be the same as a standard build
-at this point.
 
 Operating System Notes
 ----------------------
@@ -190,7 +161,7 @@ OpenBSD
 WASM
   Using the Emscripten compiler, you can achieve it like this:
 
-    cmake -DCMAKE_CXX_COMPILER=emcc -DCMAKE_BUILD_TYPE=release -DENABLE_WASM=ON \
+    cmake -DCMAKE_CXX_COMPILER=emcc -DENABLE_SYNC=OFF -DCMAKE_BUILD_TYPE=release -DENABLE_WASM=ON \
           -DCMAKE_EXE_LINKER_FLAGS="-m32 -s NO_DYNAMIC_EXECUTION=1 -s WASM=1 -s NO_EXIT_RUNTIME=1 -s INVOKE_RUN=0" \
           -DCMAKE_CXX_FLAGS_RELEASE="-O2 -m32"
 

LICENSE

@@ -21,3 +21,4 @@ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
+

NEWS

@@ -0,0 +1,152 @@
+New Features in Taskwarrior 2.6.0
+
+  - The logic behind new-uuid verbosity option changed. New-uuid now overrides
+    new-id if set and will cause Taskwarrior to display UUIDs instead of IDs
+    for new tasks (machine friendly).
+  - If ~/.taskrc is not found, Taskwarrior will look for its configuration in
+    $XDG_CONFIG_HOME/task/taskrc (defaulting to ~/.config/task/taskrc). This
+    allows users to setup their Taskwarrior to follow XDG standard without
+    using config overrides.
+  - Newer Unicode characters, such as emojis are correctly handled and displayed.
+    Taskwarrior now supports all Unicode characters up to Unicode 12.
+  - Datetime values until year 9999 are now supported.
+    Duration values of up to 1 000 000 years are now supported.
+  - 64-bit numeric values (up to 9,223,372,036,854,775,807) are now supported.
+  - Later/someday named datetime values now resolve to 9999-12-30 (instead of
+    2038-01-18).
+  - Calendar now supports displaying due dates until year 9999.
+  - Calendar now displays waiting tasks with due dates on the calendar.
+  - Calendar supports highlighting days with scheduled tasks.
+  - Multi-day holidays are now supported.
+  - Holiday data files for fr-CA, hu-HU, pt-BR, sk-SK and sv-FI locales are now
+    generated and shipped with Taskwarrior.
+  - The task edit command can now handle multi-line annotations and UDAs in a
+    user friendly way, withouth having to handle with JSON escaping of special
+    chars.
+  - A large portion of currently known parser-related issues was fixed.
+  - The taskrc file now supports relative paths, which are evaluated with
+    respect to (a) current directory, (b) taskrc directory and (c) now also the
+    installation directory of configuration files.
+  - The currently selected context is now applied for "task add" and "task log"
+    commands. Section on contexts in the manpage was updated to describe this
+    functionality.
+  - Users can specify per-context specific overrides of configuration variables.
+  - The `task import` command can now accept annotations with missing entry
+    values. Current time will be assumed.
+  - The new 'by' filter attribute modifier compares using '<=' rather than '<'
+    as 'before' uses.  This allows the last second of the day to match with
+    'due.by:eod', which it would not otherwise.  It also works with
+    whole units like days, e.g. 'add test due:2021-07-17' would not match
+    'due.before:tomorrow' (on the 16th), but would match 'due.by:tomorrow'.
+  - Waiting is now an entirely "virtual" concept, based on a task's
+    'wait' property and the current time. Task is considered "waiting" if its
+    wait attribute is in the future. TaskWarrior no longer explicitly
+    "unwaits" a task (the wait attribute is not removed once its value is in
+    the past), so the "unwait' verbosity token is no longer available.
+    This allows for filtering for tasks that were waiting in the past
+    intervals, but are not waiting anymore.
+  - The configuration file now supports environment variables.
+  - Taskwarrior can now handle displaying tasks in windows with limited width,
+    even if columns contain long strings (like URLs).
+  - The nag message is emitted at most once per task command, even with bulk
+    operations. Additionally, the urgency of the task considered is taken
+    before the completion, not after.
+  - The export command now takes an optional argument that references an
+    existing report. As such, "task export <report>" command will export
+    the same tasks that "task <report>" prints, and in the same order.
+  - The burndown command now supports non-cumulative display, where tasks only
+    get plotted within the interval segment when they got completed.
+
+
+New Commands in Taskwarrior 2.6.0
+
+  - The 'news' command will guide the user through important release notes
+    anytime a new version of Taskwarrior is installed. It provides personalized
+    feedback, deprecation warnings and usage advice, where applicable.
+
+New Configuration Options in Taskwarrior 2.6.0
+
+  - The context definitions for reporting commmands are now stored in
+    "context.<name>.read". Context definitions for write commands are now
+    supported using "context.<name>.write" configuration variable.
+  - The context-specific configuration overrides are now supported. Use
+    context.<name>.rc.<key>=<value> to override, such as
+    context.work.rc.urgency.blocking=5.0 to override the value of urgency.blocking
+    when the 'work' context is active.
+  - Each report (and the timesheet command) can explicitly opt-out from the
+    currently active context by setting the report.<name>.context variable to 0
+    (defaults to 1). Useful for defining universal reports that ignore
+    currently set context, such as 'inbox' report for GTD methodology.
+  - Multi-day holidays are now supported. Use holiday.<name>.start=<date> and
+    holiday.<name>.end=<date> to specify a range-based holiday, such as a
+    vacation.
+  - Verbosity token 'default' was introduced in order to display information
+    about default actions.
+  - The new burndown.cumulative option can be used to toggle between
+    non-cumulative and cumulative version of the burndown command.
+  - The new color.calendar.scheduled setting can be used to control the
+    highlighting color of days in the calendar that have scheduled tasks.
+
+
+Newly Deprecated Features in Taskwarrior 2.6.0
+
+  - The 'PARENT' and 'CHILD' virtual tags are replaced by 'TEMPLATE' and 'INSTANCE'.
+  - The 'waiting' status is now deprecated. We recommend using +WAITING virtual tag
+    or wait-attribute based filters, such as 'wait.before:eow' instead.
+  - The configuration variable 'monthsperline' is deprecated. Please use
+    'calendar.monthsperline' instead.
+
+Fixed regressions in 2.6.0
+
+  - The "end of <date>" named dates ('eod', 'eow', ...) were pointing to the
+    first second of the next day, instead of last second of the referenced
+    interval. This was a regression introduced in 2.5.2.
+  - The "eow" and "eonw" were using a different weekday as a reference. This
+    was a regeression introduced in 2.5.2.
+  - The rc.verbose=<value> configuration override was applied only if it were
+    the first configuration override. In #2247, this manifested itself as
+    inability to supress footnotes about the overrides, and in #1953 as failure
+    to force task to display UUIDs of on task add. This was a regression
+    introduced in 2.5.2.
+  - The attribute values of the form "<attribute name>-<arbitrary string>", for
+    example "due-nextweek" or "scheduled-work" would fail to parse (see
+    #1913). This was a regression introduced in 2.5.1.
+  - The capitalized versions of named dates (such as Monday, February or
+    Tomorrow) are again supported. This was a regression introduced in 2.5.2.
+  - The duration periods are converted to datetime values using the
+    current time as the anchor, as opposed to the beginning of unix time.
+    This was a regression in 2.5.2.
+  - Filtering for attribute values containing dashes and numbers (such as
+    'vs.2021-01', see #2392) or spaces (such as "Home renovation", see #2388)
+    is again supported. This was a regression introduced in 2.4.0.
+
+Removed Features in 2.6.0
+
+  -
+
+Other notable changes in 2.6.0
+
+  - C++17 compatible compiler is now required (GCC 7.1 or older / clang 5.0 or older).
+
+Known Issues
+
+  - https://github.com/GothenburgBitFactory/taskwarrior
+
+Taskwarrior 2.6.0 has been built and tested on the following configurations:
+
+  * Archlinux
+  * OpenSUSE
+  * macOS 10.15
+  * Fedora (31, 32, 33, 34)
+  * Ubuntu (18.04, 20.04, 21.04)
+  * Debian (Stable, Testing)
+  * CentOS (7, 8)
+
+However, we expect Taskwarrior to work on other platforms as well.
+
+---
+
+While Taskwarrior has undergone testing, bugs are sure to remain.  If you
+encounter a bug, please enter a new issue at:
+
+  https://github.com/GothenburgBitFactory/taskwarrior

README.md

@@ -2,12 +2,11 @@
 <img src="https://avatars.githubusercontent.com/u/36100920?s=200&u=24da05914c20c4ccfe8485310f7b83049407fa9a&v=4"></br>
 
 [![GitHub Actions build status](https://github.com/GothenburgBitFactory/taskwarrior/workflows/tests/badge.svg?branch=develop)](https://github.com/GothenburgBitFactory/taskwarrior/actions)
-[![Coverage Status](https://coveralls.io/repos/github/GothenburgBitFactory/taskwarrior/badge.svg?branch=develop)](https://coveralls.io/github/GothenburgBitFactory/taskwarrior?branch=develop)
 [![Release](https://img.shields.io/github/v/release/GothenburgBitFactory/taskwarrior)](https://github.com/GothenburgBitFactory/taskwarrior/releases/latest)
 [![Release date](https://img.shields.io/github/release-date/GothenburgBitFactory/taskwarrior)](https://github.com/GothenburgBitFactory/taskwarrior/releases/latest)
 [![GitHub Sponsors](https://img.shields.io/github/sponsors/GothenburgBitFactory?color=green)](https://github.com/sponsors/GothenburgBitFactory/)
-[![Gurubase](https://img.shields.io/badge/Gurubase-Ask%20Taskwarrior%20Guru-006BFF)](https://gurubase.io/g/taskwarrior)
 </br>
+[![Twitter](https://img.shields.io/twitter/follow/taskwarrior?style=social)](https://twitter.com/taskwarrior)
 </div>
 
 ## Taskwarrior
@@ -20,8 +19,16 @@ features](https://taskwarrior.org/docs/), developed as a portable open source pr
 with an active and quite vast [ecosystem of tools, hooks and
 extensions](https://taskwarrior.org/tools/).
 
+### HEADS UP! 
+### This fork is to intended to preserve the taskwarrior 2.6.2 codebase, and to allow for further fixes and improvements!!
+It's great to see that taskwarrior is still an active project and the active developers, working on version 3.x, have a vision that fuses taskchampion and an SQL database. It's cool, and in rust, and everything.. but they are decidedly uninterested in further work on the 2.x (data as text files) codebase.
+
+It was the fact that task used a text-file to store data, that first hooked me to the project. I'm almost certainly first taskwarrior user, and technically the original taskwarrior Designer! I worked with the orginal programmer, Paul Beckingham, as he brilliantly implemented so many of my crazy ideas, like colors, urgency, reports, UDAs, attribute modifiers and SO much more! 
+
+Because I'm an old fart, set im my ways like that, and kind of squeamish about keeping my task data as a SQL database, this repo is somewhare I can try to apply fixes and cherry-pick from changes made after official 2.6.2 releases, and to curate some of the things that I think belong with it. That said, I'm a terrible programmer, a dubious developer, and would welcome input, ideas and contributions.
+
 ## Install
-[![Arch](https://img.shields.io/archlinux/v/extra/x86_64/task)](https://archlinux.org/packages/extra/x86_64/task/)
+[![Arch](https://img.shields.io/archlinux/v/community/x86_64/task)](https://archlinux.org/packages/community/x86_64/task/)
 [![Debian](https://img.shields.io/debian/v/task/testing)](https://packages.debian.org/search?keywords=task&searchon=names&suite=all&section=all)
 [![Fedora](https://img.shields.io/fedora/v/task)](https://bodhi.fedoraproject.org/updates/?packages=task)
 [![Homebrew](https://img.shields.io/homebrew/v/task)](https://formulae.brew.sh/formula/task#default)
@@ -32,17 +39,23 @@ Windows](https://taskwarrior.org/download/). Check out the latest available
 packages in repositories of your OS distribution of choice [on
 Repology](https://repology.org/project/taskwarrior/versions).
 
-Alternatively, you can [build Taskwarrior from source](doc/devel/contrib).
+Alternatively, you can build Taskwarrior from source.
 
 ## Documentation
 
 The [online documentation](https://taskwarrior.org/docs), downloads, news and
 more are available on our website, [taskwarrior.org](https://taskwarrior.org).
 
+We also recommend following [@taskwarrior on
+Twitter](https://twitter.com/taskwarrior), where we share info about new
+features, releases and various tips and tricks for new Taskwarrior users.
+
 ## Community
+[![Twitter](https://img.shields.io/twitter/follow/taskwarrior?style=social)](https://twitter.com/taskwarrior)
+[![Reddit](https://img.shields.io/reddit/subreddit-subscribers/taskwarrior?style=social)](https://reddit.com/r/taskwarrior/)
+[![Libera.chat](https://img.shields.io/badge/IRC%20libera.chat-online-green)](https://web.libera.chat/#taskwarrior)
 [![Discord](https://img.shields.io/discord/796949983734661191?label=discord)](https://discord.gg/eRXEHk8w62)
 [![Github discussions](https://img.shields.io/github/discussions/GothenburgBitFactory/taskwarrior?label=GitHub%20discussions)](https://github.com/GothenburgBitFactory/taskwarrior/discussions)
-[![Reddit](https://img.shields.io/reddit/subreddit-subscribers/taskwarrior?style=social)](https://reddit.com/r/taskwarrior/)
 
 Taskwarrior has a lively community on many places on the internet.
 
@@ -51,8 +64,54 @@ Github](https://github.com/GothenburgBitFactory/taskwarrior/discussions). For
 other support options, take a look at
 [taskwarrior.org/support](https://taskwarrior.org/support)
 
-For code contributions, please use pull requests.
-See [Contributing to Taskwarrior](doc/devel/contrib) for more details.
+For code contributions, please use pull requests, or alternately send your code patches to
+[support@gothenburgbitfactory.org](mailto:support@gothenburgbitfactory.org)
+
+## Branching Model
+
+We use the following branching model:
+
+* `stable` is a branch containing the content of the latest release. Building
+  from here is the same as building from the latest tarball, or installing a
+  binary package. No development is done on the `stable` branch.
+
+* `develop` is the current development branch. All work is done here, and upon
+  release it will be merged to `stable`. While development branch is not
+  stable, we utilize CI to ensure we're at least not merging improvements that
+  break existing tests, and hence should be relatively safe. We still recommend
+  making backups when using the development branch.
+
+## Installing
+
+There are many binary packages available, but to install from source requires:
+
+* git
+* cmake
+* make
+* C++ compiler, currently gcc 7.1+ or clang 5.0+ for full C++17 support
+* uuid-dev (was libuuid-dev)
+* GnuTLS (optional, required for sync)
+
+Download the tarball, and expand it:
+
+    $ curl -O https://taskwarrior.org/download/task-2.6.2.tar.gz
+    $ tar xzf task-2.6.2.tar.gz
+    $ cd task-2.6.2
+
+Or clone this repository:
+
+    $ git clone --recursive -b stable https://github.com/GothenburgBitFactory/taskwarrior.git
+    $ cd taskwarrior
+
+Then build:
+
+    $ cmake -DCMAKE_BUILD_TYPE=release .
+    ...
+    $ make
+    ...
+    [$ make test]
+    ...
+    $ sudo make install
 
 ## Contributing
 [![Contributors](https://img.shields.io/github/contributors/GothenburgBitFactory/taskwarrior)](https://github.com/GothenburgBitFactory/taskwarrior/graphs/contributors)
@@ -61,7 +120,8 @@ See [Contributing to Taskwarrior](doc/devel/contrib) for more details.
 
 Your contributions are especially welcome.
 Whether it comes in the form of code patches, ideas, discussion, bug reports, encouragement or criticism, your input is needed.
-See further development documentation in [`doc/devel`](./doc/devel).
+
+Visit [Github](https://github.com/GothenburgBitFactory/taskwarrior) and participate in the future of Taskwarrior.
 
 ## Sponsoring
 [![GitHub Sponsors](https://img.shields.io/github/sponsors/GothenburgBitFactory?color=green)](https://github.com/sponsors/GothenburgBitFactory/)

SECURITY.md

@@ -1,13 +0,0 @@
-# Security
-
-To report a vulnerability, please contact Dustin via signal, [`djmitche.78`](https://signal.me/#eu/2T98jpkMAzvFL2wg3OkZnNrfhk1DFfu6eqkMEPqcAuCsLZPVk39A67rp4khmrMNF).
-Initial response is expected within ~48h.
-
-We kindly ask to follow the responsible disclosure model and refrain from sharing information until:
-
-1. Vulnerabilities are patched in Taskwarrior + 60 days to coordinate with distributions.
-2. 90 days since the vulnerability is disclosed to us.
-
-We recognise the legitimacy of public interest and accept that security researchers can publish information after 90-days deadline unilaterally.
-
-We will assist with obtaining CVE and acknowledge the vulnerabilities reported.

cmake.h.in

@@ -38,6 +38,9 @@
 #cmakedefine GNUHURD
 #cmakedefine UNKNOWN
 
+/* Found the GnuTLS library */
+#cmakedefine HAVE_LIBGNUTLS
+
 /* Found tm_gmtoff */
 #cmakedefine HAVE_TM_GMTOFF
 
@@ -58,3 +61,4 @@
 
 /* Undefine this to eliminate the execute command */
 #define HAVE_EXECUTE 1
+

cmake/CXXSniffer.cmake

@@ -6,8 +6,7 @@ include (CheckCXXCompilerFlag)
 CHECK_CXX_COMPILER_FLAG("-std=c++17"   _HAS_CXX17)
 
 if (_HAS_CXX17)
-  set (CMAKE_CXX_STANDARD 17)
-  set (CMAKE_CXX_EXTENSIONS OFF)
+  set (_CXX14_FLAGS "-std=c++17")
 else (_HAS_CXX17)
  message (FATAL_ERROR "C++17 support missing. Try upgrading your C++ compiler. If you have a good reason for using an outdated compiler, please let us know at support@gothenburgbitfactory.org.")
 endif (_HAS_CXX17)
@@ -33,7 +32,7 @@ elseif (${CMAKE_SYSTEM_NAME} STREQUAL "GNU")
   set (GNUHURD true)
 elseif (${CMAKE_SYSTEM_NAME} STREQUAL "CYGWIN")
   set (CYGWIN true)
-  set (CMAKE_CXX_EXTENSIONS ON)
+  set (_CXX14_FLAGS "-std=gnu++17")
 else (${CMAKE_SYSTEM_NAME} MATCHES "Linux")
   set (UNKNOWN true)
 endif (${CMAKE_SYSTEM_NAME} MATCHES "Linux")

doc/CMakeLists.txt

@@ -1,4 +1,4 @@
-cmake_minimum_required (VERSION 3.22)
+cmake_minimum_required (VERSION 3.0)
 message ("-- Configuring man pages")
 set (man_FILES task-color.5 task-sync.5 taskrc.5 task.1)
 foreach (man_FILE ${man_FILES})

doc/README.md

@@ -1,9 +0,0 @@
-# Documentation
-
-This directory contains Taskwarrior documentation that is built and installed along with the executable:
-
-* [`man`](man/) contains the source for the Taskwarrior manual pages.
-* [`rc`](rc/) contains rcfiles that will be installed in `/usr/share/doc/task/rc` or equivalent.
-* [`ref`](ref/) contains reference documentation that will be installed in `/usr/share/doc/task` or equivalent.
-
-It also contains [developer documentation](devel/README.md) with a high-level view of how Taskwarrior development is done and how the pieces of the system fit together.

doc/devel/README.md

@@ -1,16 +0,0 @@
-# Development Documentation
-
-This directory contains the _development_ documentation for Taskwarrior.
-For all other documenation, see https://taskwarrior.org.
-
- * [Contributing To Taskwarrior](contrib/README.md)
- * [Taskwarrior RFCs](rfcs/README.md)
-
-## Taskwarrior and TaskChampion
-
-As of the 3.0 release, Taskwarrior uses TaskChampion to manage task data.
-Find documentation of TaskChampion here:
-
- * [TaskChampion Repository](https://github.com/GothenburgBitFactory/taskchampion/)
- * [TaskChampion Book](https://gothenburgbitfactory.github.io/taskchampion/)
- * [TaskChampion API Documentation](https://docs.rs/taskchampion)

doc/devel/contrib/README.md

@@ -1,8 +0,0 @@
-# Contributing To Taskwarrior
-
- * [Welcome, Open Source Contributor](first_time.md)
- * [Developing Taskwarrior](development.md)
- * [Coding Style](coding_style.md)
- * [Branching Model](branching.md)
- * [Rust and C++](rust-and-c++.md)
- * [Releasing Taskwarrior](releasing.md)

doc/devel/contrib/branching.md

@@ -1,13 +0,0 @@
-Software development typically requires a standardized branching model, to manage complexity and parallel efforts.
-The branching model can be a source of confusion for developers, so this document describes how branching is used.
-
-We use the following branching model:
-
-* `develop` is the current development branch. All work is done here, and upon
-  release it will be branched to a release branch. While `develop` is not
-  stable, we utilize CI to ensure we're at least not merging improvements that
-  break existing tests, and hence should be relatively safe. We still recommend
-  making backups when using the development branch.
-
-* The most recent minor release is in a branch named after the release, e.g., `2.7.0`.
-  This branch is used for bug-fixes of the latest release.

doc/devel/contrib/coding_style.md

@@ -1,19 +0,0 @@
-# Coding Style
-
-The coding style used for the Taskwarrior is based on the [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html), with small modifications in the line length.
-
-# Automatic formatting
-
-In order to have consistancy and automatic formatting [pre-commit](https://pre-commit.com) is used to apply [clang-format](https://clang.llvm.org/docs/ClangFormat.html) and [black](https://github.com/psf/black) are used.
-In order to set them up locally please run:
-```python
-pip install pre-commit
-pre-commit install
-```
-
-For more information refer to the [quick-start of pre-commit](https://pre-commit.com/#quick-start).
-The setup is also included in the CI, hence if one can not install it automatically then the CI will take care for it in the PR.
-
-## Rust
-
-Rust code should be formatted with `rustfmt` and generally follow Rust style guidelines.

doc/devel/contrib/development.md

@@ -1,106 +0,0 @@
-# Developing Taskwarrior
-
-## Satisfy the Requirements:
-
- * CMake 3.22 or later
- * gcc 7.0 or later, clang 6.0 or later, or a compiler with full C++17 support
- * libuuid (if not on macOS)
- * Rust 1.64.0 or higher (hint: use https://rustup.rs/ instead of using your system's package manager)
-
-## Install Optional Dependencies:
- * python 3 (for running the test suite)
- * pre-commit (for applying formatting changes locally)
- * clangd or ccls (for C++ integration in many editors)
- * rust-analyzer (for Rust integration in many editors)
-
-## Obtain and Build Code:
-The following documentation works with CMake 3.14 and later.
-Here are the minimal steps to get started, using an out of source build directory and calling the underlying build tool over the CMake interface.
-See the general CMake man pages or the [cmake-documentation](https://cmake.org/cmake/help/latest/manual/cmake.1.html) for more,
-
-## Basic Building
-```sh
-git clone https://github.com/GothenburgBitFactory/taskwarrior
-cd taskwarrior
-cmake -S . -B build -DCMAKE_BUILD_TYPE=RelWithDebInfo
-cmake --build build
-```
-Other possible build types can be `Release` and `Debug`.
-This will build several executables, but the one you want is probably `src/task`, located in the `build` directory.
-When you make changes, just run the last line again.
-
-### Building a specific target
-For **only** building the `task` executable, use
-```sh
-cmake --build build --target task_executable
-```
-
-### Building in parallel
-If a parallel build is wanted use
-```sh
-cmake --build build -j <number-of-jobs>
-```
-
-### Building with clang as compiler
-```sh
-cmake -S . -B build-clang\
-    -DCMAKE_C_COMPILER=clang\
-    -DCMAKE_CXX_COMPILER=clang++
-cmake --build build-clang
-```
-
-## Run the Test Suite:
-For running the test suite [ctest](https://cmake.org/cmake/help/latest/manual/ctest.1.html) is used.
-Before one can run the test suite the `task_executable` must be built.
-After that also the `test_runner` target must be build, which can be done over:
-```sh
-cmake --build build --target test_runner
-```
-Again you may also use the `-j <number-of-jobs>` option for parallel builds.
-
-Now one can invoke `ctest` to run the tests.
-```sh
-ctest --test-dir build
-```
-This would run all the test in serial and might take some time.
-
-### Running tests in parallel
-```sh
-ctest --test-dir build -j <number-of-jobs>
-```
-
-Further it is adviced to add the `--output-on-failure` option to `ctest`, to recieve a verbose output if a test is failing as well as the `--rerun-failed` flag, to invoke in subsequent runs only the failed ones.
-
-### Running specific tests
-For this case one can use the `-R <regex>` or `--tests-regex <regex>`  option to run only the tests matching the regular expression.
-Running only the `cpp` tests can then be achieved over
-```sh
-ctest --test-dir build -R cpp
-```
-or running the `variant_*` tests
-```sh
-ctest --test-dir build -R variant
-```
-
-### Repeating a test case
-In order to find sporadic test failures the `--repeat` flag can be used.
-```sh
-ctest --test-dir build -R cpp --repeat-until-fail 10
-```
-
-There are more options to `ctest` such as `--progress`, allowing to have a less verbose output.
-They can be found in the [ctest](https://cmake.org/cmake/help/latest/manual/ctest.1.html) man page.
-
-Note that any development should be performed using a git clone, and the current development branch.
-The source tarballs do not reflect HEAD, and do not contain the test suite.
-Follow the [GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow) for creating a pull request.
-
-## Using a Custom Version of TaskChampion
-
-To build against a different version of Taskchampion, modify the requirement in `src/taskchampion-cpp/Cargo.toml`.
-
-To build from a local checkout, replace the version with a [path dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies), giving the path to the directory containing TaskChampion's `Cargo.toml`:
-
-```toml
-taskchampion = { path = "path/to/taskchampion" }
-```

doc/devel/contrib/first_time.md

@@ -1,68 +0,0 @@
-# Welcome, Open Source Contributor
-
-Welcome, potential new Open Source contributor! This is a guide to show you exactly how to make a contribution, and will lead you through the entire process.
-
-There are many people who wish to start contributing, but don't know how or where to start.
-If this might be the case for you, then please read on, this guide is for you.
-Because we want you to join in the fun with Open Source - it can be fun and rewarding, improve your skills, or just give you a way to contribute back to a project.
-
-## How to Help
-
-Help is needed in all areas of Taskwarrior development - design, coding, testing, support and marketing.
-Applicants must be friendly.
-Perhaps you are looking to help, but don't know where to start.
-Perhaps you have skills we are looking for, here are ways you may be able to help:
-
--   Use Taskwarrior, become familiar with it, and make suggestions.
-    We get great feedback from both new users and veteran users.
-    New users have a fresh approach that we can no longer achieve, while veteran users develop clever and crafty ways to use the product.
-
--   Report bugs and odd behavior when you see it.
-    We don't necessarily know it's broken, unless you tell us.
-
--   Suggest enhancements.
-    We get lots of these, and it's great.
-    Some really good ideas have been suggested and implemented.
-    Sure, some are out of scope, or plain crazy, but the stream of suggestions is fascinating to think about.
-
--   Participate in the [bug tracking](https://github.com/GothenburgBitFactory/taskwarrior/issues) database, to help others and maybe learn something yourself.
-
--   Proofread the documentation and man pages.
-
--   Improve the documentation.
-
--   Improve the man pages.
-
--   Help improve the tutorials.
-    Make your own tutorial.
-
--   Confirm a bug.
-    Nothing gets fixed without confirmation.
-
--   Refine a bug.
-    Provide relevant details, elaborate on the behavior.
-
--   Fix a bug.
-    Send a patch.
-    For this you'll need to know some C++ or Rust, and understand the [GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow).
-    See [Developing Taskwarrior](./development.md) for more information.
-    We welcome all bug fixes, provided the work is done well and doesn't create other problems or introduce new dependencies.
-    We recommend talking to us before starting: we are happy to help you out!
-
--   Write a unit test.
-    Unit tests are possibly the most useful contributions of all, because they not only improve the quality of the code, but prevent future regressions, therefore maintaining quality of subsequent releases.
-    Plus, broken tests are a great motivator for us to fix the causal defect.
-    You'll need Python skills.
-
--   Spread the word.
-    Help others become more effective at managing tasks.
-    Share your methodology, to inspire others.
-
--   Encouragement.
-    Tell us what works for you, and what doesn't.
-    It's all good.
-
--   Donate! Help offset costs.
-
-Please remember that we need contributions from all skillsets, however small.
-Every contribution helps.

doc/devel/contrib/releasing.md

@@ -1,26 +0,0 @@
-# Releasing Taskwarrior
-
-To release Taskwarrior, follow this process:
-
-- Examine the changes since the last version, and update `src/commands/CmdNews.cpp` accordingly.
-  There are instructions at the top of the file.
-- Create a release PR
-    - Update version in CMakeLists.txt
-    - Update Changelog
-    - get this merged
-- On `develop` after that PR merges, create a release tarball:
-  - `git clone . release-tarball`
-  - `cd release-tarball/`
-  - `cmake -S. -Bbuild`
-  - `make -Cbuild package_source`
-  - copy build/task-*.tar.gz elsewhere and delete the `release-tarball` dir
-  - NOTE: older releases had a `test-*.tar.gz` but it's unclear how to generate this
-- Update `stable` to the released commit and push upstream
-- Tag the commit as vX.Y.Z and push the tag upstream
-- Find the tag under https://github.com/GothenburgBitFactory/taskwarrior/tags and create a release from it
-  - Give it a clever title if you can think of one; refer to previous releases
-  - Include the tarball from earlier
-- Update https://github.com/GothenburgBitFactory/tw.org
-  - Add a new item in `content/news`
-  - Update `data/projects.json` with the latest version and a fake next version for "devel"
-  - Update `data/releases.json` with the new version, and copy the tarball into `content/download`.

doc/devel/contrib/rust-and-c++.md

@@ -1,18 +0,0 @@
-# Rust and C++
-
-Taskwarrior has historically been a C++ project, but as of taskwarrior-3.0.0, the storage backend is now provided by a Rust library called TaskChampion.
-
-## TaskChampion
-
-TaskChampion implements storage and access to "replicas" containing a user's tasks.
-It defines an abstract model for this data, and also provides a simple Rust API for manipulating replicas.
-It also defines a method of synchronizing replicas and provides an implementation of that method in the form of a sync server.
-
-Other applications, besides Taskwarrior, can use TaskChampion to manage tasks.
-Taskwarrior is just one application using the TaskChampion interface.
-
-## Taskwarrior's use of TaskChampion
-
-Taskwarrior's interface to TaskChampion is in `src/taskchampion-cpp`.
-This links to `taskchampion` as a Rust dependency, and uses [cxx](https://cxx.rs) to build a C++ API for it.
-That API is defined, and documented, in `src/taskchampion-cpp/src/lib.rs`, and available in the `tc` namespace in C++ code.

doc/devel/rfcs/README.md

@@ -1,18 +0,0 @@
-# Taskwarrior RFCS
-
-In the mid-2010's, Taskwarrior development was organized around RFCs, as a way to invite comment before designs were finalized.
-Although these documents were less formal than [IETF RFCs](https://www.ietf.org/rfc) they serve a similar purpose.
-In more recent years, use of RFCs has been discontinued, and the documents linked here should be considered historical.
-Many were never completely implemented.
-
- * [General Plans](plans.md)
- * [Rules System](rules.md)
- * [Full DOM Support ](dom.md)
- * [Work Week Support](workweek.md)
- * [Recurrence](recurrence.md)
- * [Taskwarrior JSON Format](task.md)
- * [CLI Updates ](cli.md)
- * [Taskserver Sync Protocol](protocol.md)
- * [Taskserver Message Format](request.md)
- * [Taskserver Sync Algorithm](sync.md)
- * [Taskserver Client](client.md)

doc/devel/rfcs/cli.md

@@ -1,154 +0,0 @@
----
-title: "Taskwarrior - Command Line Interface"
----
-
-## Work in Progress
-
-This design document is a work in progress, and subject to change. Once finalized, the feature will be scheduled for an upcoming release.
-
-
-# CLI Syntax Update
-
-The Taskwarrior command line syntax is being updated to allow more consistent and predictable results, while making room for new features.
-
-Adding support for arbitrary expressions on the command line has become complicated because of the relaxed syntax of Taskwarrior. While the relaxed syntax allows for a very expressive command line, it also creates ambiguity for the parser, which needs to be reduced.
-
-With some limited and careful changes it will be possible to have a clear and unambiguous command line syntax, which means a predictable and deterministic experience.
-
-It should be stated that for straightforward and even current usage patterns, the command line will likely not change for you. Another goal is to not require changes to 3rd-party software, where possible. Only the more advanced and as-yet unintroduced features will require a more strict syntax. This is why now is an ideal time to tighten the requirements.
-
-
-## Argument Types
-
-The argument types supported remain the same, adding some new constructs.
-
-* Config file override
-  * `rc:<file>`
-
-* Configuration override
-  * `rc:<name>:<value>` Literal value
-  * `rc:<name>=<value>` Literal value
-  * `rc:<name>:=<value>` Calculated value
-
-* Tag
-  * `+<tag>`
-  * `-<tag>`
-  * `'+tag one'` Multi-word tag
-
-* Attribute modifier
-  * `rc:<name>.<modifier>:<value>`
-  * Modifier is one of:
-    * `before`
-    * `after`
-    * `under`
-    * `over`
-    * `above`
-    * `below`
-    * `none`
-    * `any`
-    * `is`
-    * `isnt`
-    * `equals`
-    * `not`
-    * `contains`
-    * `has`
-    * `hasnt`
-    * `left`
-    * `right`
-    * `startswith`
-    * `endswith`
-    * `word`
-    * `noword`
-
-* Search pattern
-  * `/<pattern>/`
-
-* Substitution
-  * `/<from>/<to>/`
-  * `/<from>/<to>/g`
-
-* Command
-  * `add`
-  * `done`
-  * `delete`
-  * `list`
-  * etc.
-
-* Separator
-  * `--`
-
-* ID Ranges
-  * `<id>[-&ltid>][,<id>[-&ltid>]...]`
-
-* UUID
-  * `<uuid>`
-
-* Everything Else
-  * `<word>`
-  * `'<word> <word> ...'`
-
-
-## New Command Line Rules
-
-Certain command line constructs will no longer be supported, and this is imposed by the new rules:
-
-1.  Each command line argument may contain only one instance of one argument type, unless that type is `<word>`.
-
-        task add project:Home +tag Repair the thing     # Good
-        task add project:Home +tag 'Repair the thing'   # Good
-        task add 'project:Home +tag Repair the thing'   # Bad
-
-    Putting two arguments into one quoted arg makes that arg a `<word>`.
-
-2.  If an argument type contains spaces, it must either be quoted or escaped.
-
-        task add project:'Home & Garden' ...    # Good
-        task add 'project:Home & Garden' ...    # Good
-        task add project:Home\ \&\ Garden ...   # Good
-        task add project:Home' & 'Garden ...    # Good
-        task add project:Home \& Garden ...     # Bad
-
-    The parser will not combine multiple arguments, for example:
-
-        task '/one two/' list   # Good
-        task /one two/ list     # Bad
-        task /'one two'/ list   # Bad, unless ' is part of the pattern
-
-3.  By default, *no* calculations are made, unless the `:=` eval operator is used, and if so, the whole argument may need to be quoted or escaped to satisfy Rule 1.
-
-        task add project:3.project+x         # Literal
-        task add project:=3.project+x        # DOM reference + concatenation
-
-4.  Bare word search terms are no longer supported.
-    Use the pattern type argument instead.
-
-        task /foo/ list     # Good
-        task foo list       # Bad
-
-5.  Expressions must be a series of arguments, not a quoted string.
-
-        task urgency \< 5.0 list     # Good
-        task 'urgency < 5.0 list'    # Bad
-
-
-## Other Changes
-
-Aside from the command line parser, there are other changes needed:
-
--   Many online documents will need to be modified.
-
--   Filters will be automatically parenthesized, so that every command line will now looke like:
-
-        task [overrides] [(cli-filter)] [(context-filter)] [(report-filter)] command [modifications]
-
--   There will be more errors when the command line is not understood.
-
--   Ambiguous ISO date formats are dropped.
-
-        YYYYMMDD     # Bad
-        YYYY-MM-DD   # Good
-
-        hhmmss       # Bad
-        hh:mm:ss     # Good
-
--   The tutorial videos will be even more out of date, and will be replaced by a large number of smaller demo 'movies'.

doc/devel/rfcs/client.md

@@ -1,392 +0,0 @@
----
-title: "Taskwarrior - Creating a Taskserver Client"
----
-
-
-# Creating a Taskserver Client
-
-A Taskserver client is a todo-list manager.
-It may be as simple as a program that captures a single task, as complex as Taskwarrior, or anything in between.
-It can be a mobile client, a web application, or any other type of program.
-
-This document describes how such a client would interact with the server.
-
-A client to the Taskserver is a program that manages a task list, and wishes to exchange data with the server so that the task list may be shared.
-
-In order to do this, a client must store tasks locally, upload local changes, download remote changes, and apply remote changes to the local tasks.
-
-The client must consider that there may be no network connectivity, or no desire by the user to synchronize.
-
-The client will need proper credentials to talk to the server.
-
-## Requirements
-
-In this document, we adopt the convention discussed in Section 1.3.2 of [RFC1122](https://tools.ietf.org/html/rfc1122#page-16) of using the capitalized words MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, and OPTIONAL to define the significance of each particular requirement specified in this document.
-
-In brief: "MUST" (or "REQUIRED") means that the item is an absolute requirement of the specification; "SHOULD" (or "RECOMMENDED") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and "MAY" (or "OPTIONAL") means that this item is optional, and may be omitted without careful consideration.
-
-
-## Taskserver Account
-
-A Taskserver account must be created.
-This process creates a storage area, and generates the necessary credentials.
-
-
-## Credentials
-
-A Taskserver client needs the following credentials in order to communicate with a server:
-
--   Server address and port
--   Organization name
--   User name
--   Password
--   Certificate
--   Key
-
-The server address and port are the network location of the server.
-An example of this value is:
-
-    foo.example.com:53589
-
-In addition to a DNS name, this can be an IPv4 or IPv6 address.
-
-The organization name is an arbitrary grouping, and is typically 'PUBLIC', reflecting the individual nature of server accounts.
-Future capabilities will provide functionality that support groups of users, called an organization.
-
-The user name is the full name.
-This will be the name used to identify other users in an organization, in a future release.
-Example 'John Doe'.
-
-The password is a text string generated by the server at account creation time.
-It should be considered a secret.
-
-The certificate is an X.509 PEM file generated by the server at account creation time.
-This is used for authentication.
-It should be considered a secret.
-
-The key is an X.509 PEM file generated by the server at account creation time.
-This is used for encryption.
-It should be considered a secret.
-
-These credentials need to be stored on the client, and used during the sync operation.
-
-
-## Description of a Taskserver Client
-
-This section describes how a client might behave in order to facilitate integration with the Taskserver.
-
-
-## Encryption
-
-The Taskserver only communicates using encryption.
-Therefore all user data is encrypted while in transit.
-The Taskserver currently uses [GnuTLS](https://gnutls.org) to support this encryption, and therefore supports the following protocols:
-
--   SSL 3.0
--   TLS 1.0
--   TLS 1.1
--   TLS 1.2
-
-The client may use any library that supports the above.
-
-
-## Configuration
-
-The client needs to store configuration, which matches the credentials needed for Taskserver communication.
-See section 2.1 "Credentials".
-
-The credentials may not be modified by the user without losing server access.
-
-The server:port data may need to be changed automatically following a redirect response from the server.
-See section 5 "Server Errors".
-
-
-## Local Storage
-
-The client needs to store task data locally.
-The client will need to be able to find tasks by their UUID and overwrite them.
-Uploaded and downloaded task changes will use the [Taskwarrior Data Interchange Format](/docs/design/task).
-
-## Local Changes
-
-Whenever local data is modified, that change MUST be synced with the server.
-But this does not have to occur immediately, in fact the client SHOULD NOT assume connectivity at any time.
-
-A client SHOULD NOT also assume that the server is available.
-If the server is not available, the local changes should be retained, and the sync operation repeated later.
-
-Ideally the client will give the user full control over sync operations.
-Automatically syncing after all local modifications is not recommended.
-If a client performs too many sync operations, the server MAY revoke the certificate.
-
-Effectively, the client should maintain a separate list of tasks changed since the last successful sync operation.
-
-Note that tasks have a "modified" attribute, which should be updated whenever a change is made.
-This attribute contributes to conflict resolution on the server.
-
-
-## Remote Changes
-
-When a server sends remote changes to a client, in the response to a sync request, the changes have already been merged by the server, and therefore the client should simply store them intact.
-
-Based on the UUID in the task, the client can determine whether a task is new (and should be added to the local list of tasks), or whether it represents a modification (and should overwrite it's existing entry).
-
-The client MUST NOT perform any merges.
-
-
-## Sync Key
-
-Whenever a sync is performed, the server responds by sending a sync key and any remote changes.
-The sync key is important, and should be included in the next sync request.
-The client is REQUIRED to store the sync key in every server response message.
-
-If a client omits the sync key in a sync message, the response will be a complete set of all tasks and modifications.
-
-
-## Data Integrity
-
-Although a task is guaranteed to contain at least 'entry', 'description' and 'uuid' attributes, it may also contain other known fields, and unknown user-defined fields.
-An example might be an attribute named 'estimate'.
-
-If a task is received via sync that contains an attribute named 'estimate', then a client has the responsibility of preserving the attribute intact.
-If that data is shown, then it is assumed to be of type 'string', which is the format used by JSON for all values.
-
-Conversely, if a client wishes to add a custom attribute, it is guaranteed that the server and other clients will preserve that attribute.
-
-Using this rule, two clients of differing capabilities can exchange data and still maintain custom attributes.
-
-This is a requirement.
-Any client that does not obey this requirement is broken.
-
-
-## Synchronizing
-
-Synchronizing with the Taskserver consists of a single transaction.
-Once an encrypted connection is made with the server, the client MUST compose a [sync request message](/docs/design/request).
-This message includes credentials and local changes.
-The response message contains status and remote changes, which MUST be stored locally.
-
-
-## Establishing Encrypted Connection
-
-All communication with the Taskserver is encrypted using the certificate and key provided to each user.
-Using the 'server' configuration setting, establish a connection.
-
-
-## Sync Request
-
-See [sync request message](/docs/design/request).
-A sync request MUST contain a sync key if one was provided by a previous sync.
-A sync request MUST contain a list of modified tasks, in JSON format (see [Task JSON](/docs/design/task)), if local modifications have been made.
-
-
-## Sync Response
-
-A sync response WILL contain a 'code' and 'status' header variable, WILL contain a sync key in the payload, and MAY contain a list of tasks from the server in JSON format (see [Task JSON](/docs/design/task)).
-
-
-## Server Messages
-
-There are cases when the server needs to inform the user of some condition.
-This may be anticipated server downtime, for example.
-The response message is typically not present, but may be present in the header, containing a string:
-
-    ...
-    message: Scheduled maintenance 2013-07-14 08:00UTC for 10 minutes.
-    ...
-
-If such a message is returned by the server, it SHOULD be made available to the user.
-This is a recommendation, not a requirement.
-
-
-## Server Errors
-
-The server may generate many errors (See [Protocol](/docs/design/protocol)), but the following is a list of the ones most in need of special handling:
-
--   200 Success
--   201 No change
--   301 Redirect
--   430 Access denied
--   431 Account suspended
--   432 Account terminated
--   5xx Error
-
-The 200 indicates success, and that a change was recorded.
-The 201 indicates success but no changes were necessary.
-The 301 is a redirect message indicating that the client MUST re-request from a new server.
-The 43x series messages are account-related.
-Any 5xx series code is a server error of some kind.
-All errors consist of a code and a status message:
-
-    code: 200
-    status: Success
-
-
-## Examples
-
-Here are examples of properly formatted request and response messages.
-Note that the messages are indented for clarity in this document, but is not the case in a properly formatted message.
-Also note that newline characters U+000D are not shown, but are implied by the separate lines.
-Because some messages have trailing newline characters, the text is delimited by the 'cut' markers:
-
-    foo
-
-The example above illustrates text consisting of:
-
-    U+0066   f
-    U+006F   o
-    U+006F   o
-    U+000D   newline
-    U+000D   newline
-
-Note that these values are left unspecified, but should be clear from the context, and the [message format](/docs/design/request) spec:
-
-    <size>
-    <organization>
-    <user>
-    <password>
-
-
-## First Sync
-
-The first time a client syncs, there is (perhaps) no data to upload, and no sync key from a previous sync.
-
-    <size>type: sync
-    org: <organization>
-    user: <user>
-    key: <password>
-    client: task 2.3.0
-    protocol: v1
-
-Note the double newline character separating header from payload, with an empty payload.
-
-## Request: Sync No Data
-
-Ordinarily when a client syncs, there is a sync key from the previous sync response to send.
-This example shows a sync with no local changes, but a sync key from a previous sync.
-
-    <size>type: sync
-    org: <organization>
-    user: <user>
-    key: <password>
-    client: task 2.3.0
-    protocol: v1
-
-    2e4685f8-34bc-4f9b-b7ed-399388e182e1
-
-
-## Request: Sync Data
-
-This sync request shows a sync key from the previous sync, and a locally modified task.
-
-    <size>type: sync
-    org: <organization>
-    user: <user>
-    key: <password>
-    client: task 2.3.0
-    protocol: v1
-
-    2e4685f8-34bc-4f9b-b7ed-399388e182e1
-    {"description":"An example","uuid":"8ad2e3db-914d-4832-b0e6-72fa04f6e331",...}
-
-
-## Response: No Data
-
-If a sync results in no downloads to the client, the response will look like this.
-
-    <size>type: response
-    client: taskd 1.0.0
-    protocol: v1
-    code: 200
-    status: Ok
-
-    45da7110-1bcc-4318-d33e-12267a774e0f
-
-Note that there is a sync key which must be stored and used in the next sync request, but there are no remote changes to store.
-
-
-## Response: Remote Data
-
-This shows a sync response providing a new sync key, and a remote change to two tasks.
-
-    <size>type: response
-    client: taskd 1.0.0
-    protocol: v1
-    code: 200
-    status: Ok
-
-    45da7110-1bcc-4318-d33e-12267a774e0f
-    {"description":"Test data","uuid":"8ad2e3db-914d-4832-b0e6-72fa04f6e331",...}
-    {"description":"Test data2","uuid":"3b6218f9-726a-44fc-aa63-889ff52be442",...}
-
-Note that the sync key must be stored for the next sync request.
-
-Note that the two changed tasks must be stored locally, and if the UUID in the tasks matches local tasks, then the local tasks must be overwritten.
-
-
-## Response: Error
-
-    <size>type: response
-    client: taskd 1.0.0
-    protocol: v1
-    code: 431
-    status: Account suspended
-
-Note the double newline character separating header from payload, with an empty payload.
-
-
-## Response: Relocate
-
-    <size>type: response
-    client: taskd 1.0.0
-    protocol: v1
-    code: 301
-    status: Redirect
-    info:
-
-Note the 'info' field will contain a ':' string that should be used for all future sync requests.
-This indicates that a user account was moved to another server.
-
-Note the double newline character separating header from payload, with an empty payload.
-
-
-## Response: Message
-
-Occasionally the server will need to convey a message, and will include an additional header variable containing that message.
-
-The server [protocol](/docs/design/protocol) states that the message SHOULD be shown to the user.
-This message will be used for system event messages, used rarely, and never used for advertising or promotion.
-
-    <size>type: response
-    client: taskd 1.0.0
-    protocol: v1
-    code: 200
-    status: Ok
-    message: Scheduled maintenance 2013-07-14 08:00UTC for 10 minutes.
-
-    45da7110-1bcc-4318-d33e-12267a774e0f
-
-Note that the same message will likely be included in consecutive responses.
-
-
-## Reference Implementation
-
-The Taskserver 1.1.0 codebase contains a reference implementation of an SSL/TLS client and server program, which communicate text strings.
-
-    taskd.git/src/tls/Makefile             # To build the example
-    taskd.git/src/tls/README               # How to run the example
-    taskd.git/src/tls/TLSClient.cpp        # TLS client code
-    taskd.git/src/tls/TLSClient.h
-    taskd.git/src/tls/TLSServer.cpp        # TLS Server code
-    taskd.git/src/tls/TLSServer.h
-    taskd.git/src/tls/c.cpp                # Client program
-    taskd.git/src/tls/s.cpp                # Server program
-    taskd.git/src/tls/text.cpp             # Text manipulation
-    taskd.git/src/tls/text.h               # Text manipulation
-
-The Taskwarrior codebase, version 2.4.0, is the reference implementation.
-
-    task.git/src/TLSClient.cpp             # TLS client code
-    task.git/src/TLSClient.h
-    task.git/src/commands/CmdSync.cpp      # Sync implementation
-    task.git/src/commands/CmdSync.h

doc/devel/rfcs/dom.md

@@ -1,249 +0,0 @@
----
-title: "Taskwarrior - Full DOM Support"
----
-
-## Work in Progress
-
-This design document is a work in progress, and subject to change.
-Once finalized, the feature will be scheduled for an upcoming release.
-
-
-# Full DOM Support
-
-Taskwarrior currently supports DOM references that can access any stored data item.
-The general forms supported are:
-
-    [ <id> | <uuid> ] <attribute> [ <part> ]
-
-Examples include:
-
-    due
-    123.uuid
-    entry.month
-    123.annotations.0.entry.year
-    a87bc10f-931b-4558-a44a-e901a77db011.description
-
-Additionally there are references for accessing configuration and system/program level items.
-
-    rc.<name>
-    context.program
-    context.args
-    context.width
-    context.height
-    system.version
-    system.os
-
-While this is adequate for data retrieval, we have the possibility of extending it further to include data formats, higher-level constructs, and then to make use of DOM references in more locations.
-This contributes to our goal of simplifying Taskwarrior.
-
-
-## Proposed Format Support
-
-When defining a custom report, the columns shown are defined like this:
-
-    report.x.columns=uuid.short,description.oneline ...
-
-This syntax is:
-
-    <attribute> [ . <format> ]
-
-If no `format` is specified, then `default` is assumed.
-The `src/columns/ColΧ\*` objects are responsible for supporting and rendering these formats.
-There is currently no consistency among these formats based on data type.
-
-By incorporating formats into DOM references, we eliminate the need for a separate syntax for custom reports, and provide this:
-
-    123.due.iso
-    123.due.month.short
-    123.uuid.short
-
-A standard set of formats per data type would be:
-
-Type
-
-Formats
-
-Example
-
-Numeric
-
-default
-
-`123                              `
-
-indicator
-
-Based on `rc.<attribute>.indicator` which overrides `rc.numeric.indicator`.
-
-json
-
-`"<attribute>":"<value>"`
-
-String
-
-default
-
-Buy milk
-
-short
-
-Feb
-
-indicator
-
-Based on `rc.<attribute>.indicator` which overrides `rc.string.indicator`.
-
-json
-
-`"<attribute>":"<value>"`
-
-Date
-
-default
-
-Based on `rc.dateformat`
-
-iso
-
-2017-02-20T09:02:12
-
-julian
-
-2457805.12858
-
-epoch
-
-1234567890
-
-age
-
-2min
-
-relative
-
--2min
-
-remaining
-
-0:02:04
-
-countdown
-
-0:02:04
-
-indicator
-
-Based on `rc.<attribute>.indicator` which overrides `rc.date.indicator`.
-
-json
-
-`"<attribute>":"<value>"`
-
-Duration
-
-default
-
-1wk
-
-iso
-
-P1W
-
-indicator
-
-Based on `rc.<attribute>.indicator` which overrides `rc.duration.indicator`.
-
-json
-
-`"<attribute>":"<value>"`
-
-There will also be a set of attribute-specific formats, similar to the currently supported set:
-
-    depends.list
-    depends.count
-    description.combined
-    description.desc
-    description.oneline
-    description.truncated
-    description.count
-    description.truncated_count
-    parent.default|long
-    parent.short
-    project.full
-    project.parent
-    project.indented
-    status.default|long
-    status.short
-    tags.default|list
-    tags.count
-    urgency.default|real
-    urgency.integer
-    uuid.default|long
-    uuid.short
-
-Custom report sort criteria will also use DOM references.
-This will be augmented by the `+`/`-` sort direction and `/` break indicator, which are not part of the DOM.
-
-
-## High Level Construct Support
-
-There need to be read-only DOM references that do not correspond directly to stored attributes.
-Tasks have emergent properties represented by virtual tags, which will be accessible, in this case returning a `0` or `1`:
-
-    123.tags.OVERDUE
-
-Using `rc.due` and the `due` attribute, the `OVERDUE` virtual tag is a combination of the two.
-Other examples may include:
-
-    task.syncneeded
-    task.pending.count
-    task.hooks.installed
-
-
-## Writable References
-
-When a DOM reference refers to an attribute or RC setting, and does not extend further and reference a component or format, it may be writable.
-For example:
-
-    rc.hooks           # writable
-    123.description    # writable
-    123.entry.month    # not writable, not an attribute
-
-
-## Data Interchange
-
-The export command can be used to show a filtered set of tasks in JSON format, and this will also be available as a DOM format:
-
-    123.json
-    a87bc10f-931b-4558-a44a-e901a77db011.json
-
-
-## RC File Support
-
-The RC file (`~/.taskrc`) will support DOM references in values.
-This will form a late-bound reference, which is evaluated at runtime, every time.
-
-An example is to make two reports share the same description:
-
-    $ task config -- report.ls.description rc.report.list.description
-
-This sets the description for the `ls` report to be a reference to the description of the `list` report.
-This reference is not evaluated when the entry is written, but is evaluated every time the value is read, thus providing late-bound behavior.
-Then if the description of the `list` report changes, so does that of the `ls` report automatically.
-
-
-## Implementation Details
-
-These notes list a series of anticipated changes to the codebase.
-
--   The `src/columns/Col*` objects will implement type-specific and attribute-specific DOM support.
-    DOM reference lookup will defer to the column objects first.
-
--   Some DOM references will be writable, permitting a `_set` command to complement the `_get` command.
-
--   The `Config` object will recognize DOM references in values and perform lookup at read time.
-    This will require circularity detection.
-
--   `src/DOM.cpp` will provide a memoized function to determine whether a DOM reference is valid.
-
--   `src/DOM.cpp` will provide a function to obtain a DOM reference value, with supporting metadata (type, writable).

doc/devel/rfcs/plans.md

@@ -1,436 +0,0 @@
----
-title: "Plans"
----
-
-There are many interconnected features and technologies in Taskwarrior, Taskserver, Tasksh and Timewarrior, each piece having it's own goals.
-
-This matrix allows a simple reading of where things are, and where they are going.
-This is a low-resolution time line.
-It is subject to change.
-It does not constitute a concrete plan.
-This is an all-volunteer effort, and scheduling is difficult.
-
-[Last updated 2016-08-08.]
-
-<table class="table table-bordered table-striped">
-<tr>
-  <th>Taskwarrior<br />Technology/Feature</th>
-  <th>
-    <span class="label label-success">2.5.1</span><br />
-    Current<br /><br />
-    Released 2016-02-24
-  </th>
-  <th>
-    <span class="label label-danger">2.6.0</span><br />
-    Next<br /><br />
-    2017
-  </th>
-  <th>
-    <span class="label label-info">2.x</span><br />
-    Future
-  </th>
-</tr>
-
-<tr>
-  <td>Core</td>
-  <td>
-    <a href="/docs/dom.html">DOM</a><br />
-    Filters<br />
-    Expressions<br />
-    Color Rules<br />
-    Custom Reports<br />
-    Annotations<br />
-    Tags / Virtual Tags<br />
-    <a href="/docs/context.html">Context</a><br />
-  </td>
-  <td>
-    <a href="/docs/design/recurrence.html">Recurrence</a><br />
-    Shared library<br />
-    <code>purge</code> command<br />
-  </td>
-  <td>
-    True Color
-  </td>
-</tr>
-
-<tr>
-  <td>API</td>
-  <td>
-    <a href="/docs/design/task.html">JSON</a><br />
-    Import<br />
-    Export<br />
-    <a href="/docs/hooks.html">Hooks</a><br />
-    <a href="/docs/hooks2.html">Hooks v2</a><br />
-    <a href="/docs/dom.html">DOM</a><br />
-    Helper commands<br />
-  </td>
-  <td>
-  </td>
-  <td>
-    <code>on-sync</code> hook<br />
-    Full DOM<br />
-    DOM access in rc<br />
-    <code>$ENV</code> access in rc<br />
-    Report columns as DOM refs<br />
-  </td>
-</tr>
-
-<tr>
-  <td>
-    Attributes<br />
-    <a href="/docs/udas.html">User Defined Attributes (UDA)</a>
-  </td>
-  <td>
-    <code>modified</code><br />
-    <code>priority</code> as a UDA<br />
-  </td>
-  <td>
-    <code>template</code><br />
-    <code>rtype</code><br />
-    Remove <code>mask</code><br />
-    Remove <code>imask</code><br />
-    Remove <code>parent</code><br />
-  </td>
-  <td>
-    <code>org</code><br />
-    <code>group</code><br />
-  </td>
-</tr>
-
-<tr>
-  <td>Reports</td>
-  <td>
-    Improved layouts<br />
-    Improved Themes
-  </td>
-  <td>
-    Daily, Weekly reports (history, ghistory)<br />
-  </td>
-  <td>
-  </td>
-</tr>
-
-<tr>
-  <td>Synchronization</td>
-  <td>
-    <code>task sync</code><br />
-    <code>task sync init</code> (all tasks)<br />
-  </td>
-  <td>
-  </td>
-  <td>
-    <code>task sync reset</code><br />
-  </td>
-</tr>
-
-<tr>
-  <td>TDB (task database)</td>
-  <td>
-    Local file locking<br />
-    Single file set<br />
-    Single user
-  </td>
-  <td>
-  </td>
-  <td>
-    Threaded file load<br />
-    Read-only mode
-  </td>
-</tr>
-
-<tr>
-  <td>I18N / L10N</td>
-  <td>
-    UTF-8 support<br />
-    <code>deu-DEU</code><br />
-    <code>eng-USA</code><br />
-    <code>epo-RUS</code><br />
-    <code>esp-ESP</code><br />
-    <code>fra-FRA</code><br />
-    <code>ita-ITA</code><br />
-    <code>pol-POL</code><br />
-    <code>por-PRT</code><br />
-  </td>
-  <td>
-    No I18N / L10N
-  </td>
-  <td>
-    Migrate to <a href="https://www.gnu.org/software/gettext/">gettext</a><br />
-  </td>
-</tr>
-
-<tr>
-  <td>Documentation</td>
-  <td>
-    man: task<br />
-    man: taskrc<br />
-    man: task-color<br />
-    man: task-sync<br />
-    youtube: various<br />
-    <a href="https://taskwarrior.org">taskwarrior.org</a><br />
-    taskwarrior.com: Support Site<br />
-  </td>
-  <td>
-  </td>
-  <td>
-    New video tutorials<br />
-  </td>
-</tr>
-
-<tr>
-  <td>Testing</td>
-  <td>
-    C++ tests<br />
-    Python tests<br />
-    Sync tests<br />
-    Parallel tests<br />
-  </td>
-  <td>
-    Migration to Flod2<br />
-  </td>
-  <td>
-  </td>
-</tr>
-
-<tr>
-  <td>Tool Chain</td>
-  <td>
-    GCC 4.7 / Clang 3.3<br />
-    C++11 support<br />
-    CMake<br />
-  </td>
-  <td>
-    GCC 4.9 / Clang 3.4<br />
-    Full C++11 support<br />
-  </td>
-  <td>
-    Full C++14 support<br />
-    Full C++17 support<br />
-  </td>
-</tr>
-</table>
-
-<table class="table table-bordered table-striped">
-<tr>
-  <th>Tasksh<br />Technology/Feature</th>
-  <th>
-    <span class="label label-success">1.1.0</span><br />
-    Current<br /><br />
-    Released 2016-09-05
-  </th>
-  <th>
-    <span class="label label-danger">1.2.0</span><br />
-    Next<br /><br />
-    2017
-  </th>
-  <th>
-    <span class="label label-info">1.x</span><br />
-    Future
-  </th>
-</tr>
-
-<tr>
-  <td>Core</td>
-  <td>
-    <a href="/docs/review.html">Review</a><br />
-    libreadline<br />
-    Shared library<br />
-  </td>
-  <td>
-  </td>
-  <td>
-    Pomodoro timer<br />
-  </td>
-</tr>
-
-<tr>
-  <td>Tool Chain</td>
-  <td>
-    CMake<br />
-    GCC 4.7 / Clang 3.3<br />
-  </td>
-  <td>
-    GCC 4.9 / Clang 3.4<br />
-    Full C++11 support<br />
-  </td>
-  <td>
-    Full C++14 support<br />
-    Full C++17 support<br />
-  </td>
-</tr>
-</table>
-
-<table class="table table-bordered table-striped">
-<tr>
-  <th>Taskserver<br />Technology/Feature</th>
-  <th>
-    <span class="label label-success">1.1.0</span><br />
-    Current<br /><br />
-    Released 2015-05-10
-  </th>
-  <th>
-    <span class="label label-danger">1.2.0</span><br />
-    Next<br /><br />
-    2017
-  </th>
-  <th>
-    <span class="label label-info">1.x</span><br />
-    Future
-  </th>
-</tr>
-
-<tr>
-  <td>Core</td>
-  <td>
-    Serial server
-  </td>
-  <td>
-    Shared library<br />
-  </td>
-  <td>
-    Threaded server
-  </td>
-</tr>
-
-<tr>
-  <td>Protocol</td>
-  <td>
-    v1
-  </td>
-  <td>
-    v1.1 - client reset request<br />
-  </td>
-  <td>
-    v1.2
-  </td>
-</tr>
-
-<tr>
-  <td>DB (Data Storage)</td>
-  <td>
-  </td>
-  <td>
-  </td>
-  <td>
-    GC
-  </td>
-</tr>
-
-<tr>
-  <td>Security</td>
-  <td>
-    Validation
-  </td>
-  <td>
-  </td>
-  <td>
-    UUID:Cert Verification<br />
-    Combined Certs
-  </td>
-</tr>
-
-<tr>
-  <td>Tool Chain</td>
-  <td>
-    GCC 4.7 / Clang 3.3<br />
-    CMake<br />
-  </td>
-  <td>
-    GCC 4.9 / Clang 3.4<br />
-    Full C++11 support<br />
-  </td>
-  <td>
-    Full C++14 support<br />
-    Full C++17 support<br />
-  </td>
-</tr>
-</table>
-
-
-<table class="table table-bordered table-striped">
-<tr>
-  <th>Timewarrior<br />Technology/Feature</th>
-  <th>
-    <span class="label label-success">1.0.0</span><br />
-    Current<br /><br />
-    Released 2016-08-20
-  </th>
-  <th>
-    <span class="label label-danger">1.1.0</span><br />
-    Next<br /><br />
-    2017
-  </th>
-  <th>
-    <span class="label label-info">1.x</span><br />
-    Future
-  </th>
-</tr>
-
-<tr>
-  <td>Core</td>
-  <td>
-    Shared library<br />
-  </td>
-  <td>
-  </td>
-  <td>
-    True Color
-  </td>
-</tr>
-
-<tr>
-  <td>Reports</td>
-  <td>
-    <code>summary</code> report<br />
-    <code>gaps</code> report<br />
-    <code>day</code> chart<br />
-    <code>week</code> chart<br />
-    <code>month</code> chart<br />
-    <code>totals.py</code> extension<br />
-  </td>
-  <td>
-  </td>
-  <td>
-  </td>
-</tr>
-
-<tr>
-  <td>Rules</td>
-  <td>
-    Simple configuration rules
-  </td>
-  <td>
-  </td>
-  <td>
-    Rule System<br />
-  </td>
-</tr>
-
-<tr>
-  <td>Integration</td>
-  <td>
-    Taskwarrior <code>on-modify</code> hook script
-  </td>
-  <td>
-  </td>
-  <td>
-  </td>
-</tr>
-
-<tr>
-  <td>Tool Chain</td>
-  <td>
-    CMake<br />
-    GCC 4.7 / Clang 3.3<br />
-    C++11 support<br />
-  </td>
-  <td>
-    GCC 4.9 / Clang 3.4<br />
-    Full C++11 support<br />
-  </td>
-  <td>
-    Full C++14 support<br />
-    Full C++17 support<br />
-  </td>
-</tr>
-</table>

doc/devel/rfcs/protocol.md

@@ -1,171 +0,0 @@
----
-title: "Taskwarrior - Sync Protocol"
----
-
-
-# Sync Protocol
-
-
-## Introduction
-
-Taskwarrior data has typically been shared in several ways.
-Those include SCM (source code management) systems, directory synchronizing software (such as DropBox), and by use of the 'push', 'pull' and 'merge' commands introduced in version 1.9.3.
-
-While these methods work, they each have problems associated with the merging of data.
-In the case of directory synchronizing software, there is no merging at all - just simple file overwrite, despite many people believing that the data is somehow combined and preserved.
-
-The Taskserver is a solution.
-It is an online/cloud storage and sync service for taskwarrior data.
-It performs conflict-free data merging, and minimizes bandwidth use.
-
-The Taskserver also provides multi-client access, so that a task added using a web client could be immediately viewed using a mobile client, or modified using taskwarrior.
-Choice of clients is important - people have widely varying behaviors and tastes.
-
-The Taskserver also provides multi-user access, which introduces new capabilities, such as list sharing and delegation.
-These will require later modification to this protocol.
-
-The Taskserver protocol will be implemented by the taskd project and first used in taskwarrior 2.3.0.
-Other clients will follow.
-
-
-## Requirements
-
-In this document, we adopt the convention discussed in Section 1.3.2 of [RFC1122](https://tools.ietf.org/html/rfc1122#page-16) of using the capitalized words MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, and OPTIONAL to define the significance of each particular requirement specified in this document.
-
-In brief: "MUST" (or "REQUIRED") means that the item is an absolute requirement of the specification; "SHOULD" (or "RECOMMENDED") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and "MAY" (or "OPTIONAL") means that this item is optional, and may be omitted without careful consideration.
-
-
-## Link Level
-
-The Taskserver protocol assumes a reliable data stream such as provided by TCP.
-When TCP is used, a Taskserver listens on a single predetermined port *for the given client* only.
-This means the server may be using multiple ports to serve distinct sets of clients.
-
-This server is only an interface between programs and the task data.
-It does not perform any user interaction or presentation-level functions.
-
-
-## Transactions
-
-Each transaction is a single incoming message, with a single response message.
-All communication therefore consists of a single 'send', followed by a single 'receive', then termination.
-There are no sessions, and no continuously open connections.
-The message format is described in the [Taskserver Message Format](/docs/design/request) document.
-
-
-## Responsibilities of the Server
-
-The server will maintain a set of transactions, in the original sequence, punctuated by sync keys which are UUIDs.
-Each sync key represents a non- trivial sync operation by a client.
-Each transaction is a [JSON-formatted task](/docs/design/task), followed by a newline (\\n) character.
-The result is a single file that contains interleaved lines of two types: tasks and sync keys.
-
-This design allows the server to maintain a set of deltas such that multiple clients may request a minimal set of changes since their last sync.
-
-
-## Responsibilities of the Client
-
-This describes how Taskwarrior implements sync.
-
-All modifications to tasks (add, modify, done, delete \...) are recorded in the form of a fully-composed [JSON-formatted task](/docs/design/task).
-The formatted task is added to a local backlog.data file.
-If a task is modified a second time, it is added again to the backlog.data file - the lines are not combined.
-Each task SHALL have a 'modified' date attribute that will help resolve conflicts.
-
-On sync:
-
-*   Send a 'sync' type message with the entire contents of the backlog.data, unmodified, as the message payload.
-
-*   Receive one of the following response codes:
-
-  *   201: This means 'no change', and there is no further action to be taken.
-
-  *   200: This means 'success', and the message payload contains a set of tasks and a sync key:
-
-    *   The formatted tasks are to be stored as-is.
-        These tasks will either be appended to the client data or will overwrite existing client data, based on the UUID of the task.
-        No merge logic is necessary.
-
-    *   The sync key will be written to the backlog.data file, overwriting the previous contents, such that it will now contain only one line.
-
-    *   301: Redirect to : found in the 'info' response header, will force the client to resubmit the request to the new server.
-
-    *   3xx, 4xx, 5xx: The 'status' field contains an error message.
-
-*   If the response contained any error or warning, the error should be shown to the user.
-    This provides an opportunity for the server to announce downtime, or relocation.
-
-If no sync key is sent, the server cannot provide an incremental delta, and so will send all task data, which should be stored as above.
-This should be the case for a client making its first sync call.
-
-If an unrecognized attribute is present in the task data, the client MUST preserve the attribute unmodified, and assume it is of type 'string'.
-This permits individual clients to augment the task data without other clients stripping it meaningful data.
-This is how UDAs (user defined attributes) are handled.
-
-
-## Extensions
-
-This protocol was designed so that extensions to the protocol will take the form of additional message types and status codes.
-
-
-## Summary of Response Codes
-
-Status responses indicate the server's response to the last command received from the client.
-The codes consist of a 3 digit numeric code.
-
-The first digit of the response broadly indicates the success, failure, or progress of the previous command (based generally on [RFC640](https://tools.ietf.org/html/rfc640) [RFC821](https://tools.ietf.org/html/rfc821)):
-
-| 1yz | Positive Preliminary reply           |
-| 2yz | Positive Completion reply            |
-| 3yz | Positive Intermediate reply          |
-| 4yz | Transient Negative Completion reply  |
-| 5yz | Permanent Negative Completion reply  |
-
-The next digit in the code indicates the response category:
-
-| x0z |  Syntax                                           |
-| x1z |  Information (e.g., help)                         |
-| x2z |  Connections                                      |
-| x3z |  Authentication                                   |
-| x4z |  Unspecified as yet                               |
-| x5z |  Taskd System (\...)                              |
-| x8z |  Nonstandard (private implementation) extensions  |
-
-A summary of all status response are:
-
-| 200 | Success   |
-| 201 | No change |
-| 300 | Deprecated message type. This message will not be supported in future Taskserver releases.                                                   |
-| 301 | Redirect. Further requests should be made to the specified server/port.                                                                      |
-| 302 | Retry. The client is requested to wait and retry the same request. The wait time is not specified, and further retry responses are possible. |
-| 400 | Malformed data |
-| 401 | Unsupported encoding |
-| 420 | Server temporarily unavailable |
-| 421 | Server shutting down at operator request |
-| 430 | Access denied |
-| 431 | Account suspended |
-| 432 | Account terminated |
-| 500 | Syntax error in request |
-| 501 | Syntax error, illegal parameters |
-| 502 | Not implemented |
-| 503 | Command parameter not implemented |
-| 504 | Request too big |
-
-## Security Considerations
-
-All communication with the Taskserver uses SSL 3.0 or TLS 1.0, 1.1 or 1.2.
-Encryption is mandatory.
-Data is never transmitted in plain text.
-
-
-## Limitations and Guidelines
-
-Some limitations exists to reduce bandwidth and load on the server.
-They are:
-
--   A client may only connect to a single server.
-    Synchronization among a set of servers is not supported.
-
--   A client should attempt to minimize data bandwidth usage by maintaining a local data store, and properly using sync keys.
-
--   A client should minimize data transfers by limiting the frequency of sync requests.

doc/devel/rfcs/recurrence.md

@@ -1,195 +0,0 @@
----
-title: "Taskwarrior - Recurrence"
----
-
-# Draft
-
-This is a draft design document.
-Your [feedback](mailto:support@taskwarrior.org?Subject=Feedback) is welcomed.
-
-Recurrence
-----------
-
-Recurrence needs an overhaul to improve weaknesses and add new features.
-
-# Terminology
-
--   The hidden 'parent' task is called the template.
--   Synthesis is the name for the generation of new recurring task instances when necessary.
--   The synthesized tasks are called instances.
--   The index is the zero-based monotonically increasing number of the instance.
--   Drift is the accumulated errors in time that cause a due date to slowly change for each recurring task.
-
-# Criticism of Current Implementation
-
--   The `mask` attribute grows unbounded.
--   Only strict recurrence cycles are supported.
-    The example of mowing the lawn is that you want to mow the lawn every seven days, but when you are four days late mowing the lawn, the next mowing should be in seven days, not in three.
--   Intances generated on one machine and then synced, may collide with equivalent unsynced instances tasks on another device, because the UUIDs are different.
--   You cannot `wait` a recurring task and have that wait period propagate to all other child tasks.
--   Task instances cannot individually expire.
-
-# Proposals
-
-## Proposal: Eliminate `mask`, `imaѕk` Attributes
-
-The `mask` attribute in the template is replaced by `last`, which indicates the most recent instance index synthesized.
-Because instances are never synthesized out of order, we only need to store the most recent index.
-The `imask` attribute in the instance is no longer needed.
-
-## Proposal: Rename `parent` to `template`
-
-The name `parent` implies subtasks, and confuses those who inspect the internals.
-The value remains the UUID of the template.
-This frees up the namespace for future use with subtasks.
-
-## Proposal: New 'rtype' attribute
-
-To indicate the flavor of recurrence, support the following values:
-
-* `periodic` - Instances are created on a regular schedule.
-  Example: send birthday flowers.
-  It must occur on a regular schedule, and doesn't matter if you were late last year.
-  This is the default value.
-
-* `chained` - Instances are created back to back, so when one instance ends, the next begins, with the same recurrence.
-  Example: mow the lawn.
-  If you mow two days late, the next instance is not two days early to compensate.
-
-## Proposal: Use relative offsets
-
-The delta between `wait` and `due` date in the template should be reflected in the delta between `wait` and `due` date in the instance.
-Similarly, 'scheduled' must be handled the same way.
-
-## Proposal: On load, auto-upgrade legacy tasks
-
-Upgrade template:
-
--   Add `rtype:periodic`
--   Add `last:N` where `N` is the length of `mask`
--   Delete `mask`
-
-Upgrade instance:
-
--   Rename `parent` to `template`
--   Delete `imask`
--   Update `wait` if not set to: `wait:due + (template.due - template.wait)`
--   Update `scheduled` if not set to: `scheduled:due + (template.due - template.scheduled)`
-
-## Proposal: Deleting a chained instance
-
-Deleting a `rtype:chained` instance causes the next chained instance to be synthesized.
-This gives the illusion that the due date is simply pushed out to `(now + template.recur)`.
-
-## Proposal: Modification Propagation
-
-TBD
-
-## Proposal: Exotic Dates
-
-Expand date specifications to use pattern phrases:
-
--   `4th thursday in November`
--   `4th thursday of November`
--   `Friday before easter`
--   `next Tuesday`
--   `last Tuesday`
--   `last July`
--   `weekend`
--   `3 days before eom`
--   `in the morning`
--   `4pm`
--   `noon`
--   `midnight`
-
-Got suggestions?
-
-## Proposal: User-Defined Week Start
-
-TBD
-
-# Implementation
-
-## Implementation: Adding a new `periodic` template
-
-When adding a new periodic template:
-
-    task add ... due:D recur:R wait:D-1wk scheduled:D-1wk until:U
-
-Creates:
-
-    template.uuid:        NEW_UUID
-    template.description: ...
-    template.entry:       now
-    template.modified:    now
-    template.due:         D
-    template.recur:       R       (stored in raw form, ie 'P14D')
-    template.wait:        D-1wk
-    template.scheduled:   D-1wk
-    template.until:       U
-    template.rtype:       periodic
-    template.last:
-
-Creating the Nth instance (index N):
-
-    Clone instance from template.
-
-    instance.uuid:        NEW_UUID
-    instance.modified:    now
-    instance.due:         template.due + (N * template.recur)
-    instance.wait:        instance.due + (template.due - template.wait)
-    instance.scheduled:   instance.due + (template.due - template.scheduled)
-    instance.start:
-
-    template.last:        N
-
-## Implementation: Adding a new `chained` template
-
-When adding a new chained template:
-
-    task add ... due:D recur:R wait:D-1wk scheduled:D-1wk until:U rtype:chained
-
-Creates:
-
-    template.uuid:        NEW_UUID
-    template.description: ...
-    template.entry:       now
-    template.modified:    now
-    template.due:         D
-    template.recur:       R       (stored in raw form, ie 'P14D')
-    template.wait:        D-1wk
-    template.scheduled:   D-1wk
-    template.until:       U
-    template.rtype:       chained
-
-Creating the Nth instance (index N):
-
-    Clone instance from template.
-
-    instance.uui  d:        NEW_UUID
-    instance.mod  ified:    now
-    instance.due  :         instance[N-1].end + template.recur
-    instance.wai  t:        instance.due + (template.due - template.wait)
-    instance.sch  eduled:   instance.due + (template.due - template.scheduled)
-    instance.sta  rt:
-
-Chained tasks do not obey `rc.recurrence.limit`, and show only one pending task
-at a time.
-
-## Implementation: Special handling for months
-
-Certain recurrence periods are inexact:
-
--   P1M
--   P1Y
--   P1D
-
-When the recurrence period is `P1M` the number of days in a month varies and causes drift.
-
-When the recurrence period is `P1Y` the number of days in a year varies and causes drift.
-
-When the recurrence period is `P1D` the number of hours in a day varies due to daylight savings, and causes drift.
-
-Drift should be avoided by carefully implementing:
-
-    instance.due: template.due + (N * template.recur)

doc/devel/rfcs/request.md

@@ -1,198 +0,0 @@
----
-title: "Taskwarrior - Request"
----
-
-# Taskserver Message Format
-
-The Taskserver accepts and emits only messages.
-These messages look somewhat like email, as defined in [RFC821](https://tools.ietf.org/html/rfc821), [RFC2822](https://tools.ietf.org/html/rfc2822).
-
-The message format allows for data, metadata, and extensibility.
-This combination allows the Taskserver to accommodate current and future needs.
-This document describes the message format, and the supported message types.
-
-## Requirements
-
-In this document, we adopt the convention discussed in Section 1.3.2 of [RFC1122](https://tools.ietf.org/html/rfc1122#page-16) of using the capitalized words MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, and OPTIONAL to define the significance of each particular requirement specified in this document.
-
-In brief: "MUST" (or "REQUIRED") means that the item is an absolute requirement of the specification; "SHOULD" (or "RECOMMENDED") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and "MAY" (or "OPTIONAL") means that this item is optional, and may be omitted without careful consideration.
-
-## Encoding
-
-All messages are UTF8-encoded text.
-
-## Message Format
-
-This format is based on [RFC2822](https://tools.ietf.org/html/rfc2822), 'Internet Message Format'.
-Here is an example of the format:
-
-    <SIZE>
-    name: value
-    name2: value2
-
-    payload
-
-There are three sections.
-The first is the size, which is a 4-byte, big- Endian, binary byte count of the length of the message, including the 4 bytes for the size.
-
-The header section is a set of name/value pairs separated by newline characters (U+000D).
-The name is separated from the value by ': ' (colon U+003A, space U+0020) The header section is terminated by two consecutive newline (U+000D) characters.
-All text is UTF8-encoded.
-
-The payload section is arbitrary, and message type-specific.
-However, it is still UTF8-encoded text.
-
-
-## Message Requirements
-
-Messages SHALL contain particular headers.
-Those are:
-
--   type
--   protocol
--   client
-
-The 'type' value is what determines the interpretation of the payload.
-
-The 'protocol' value should be 'v1', or any subsequently published protocol version.
-
-The 'client' represent the client identifier, so that any special cases can be handled.
-For example, an emergency fix that is client version-specific could be released, to support users that have not updated their client, or perhaps the client has not released a fix.
-The form of the 'version' value is:
-
-    <product identifier> <version number>
-
-As an example:
-
-    taskwarrior 2.3.0
-
-DO NOT spoof any other software using this client value.
-If another client is spoofed, then patches addressing protocol errors may break working software.
-
-
-## Auth Data
-
-Every request from the client SHALL contain "auth" information, which involves these header entries:
-
-    org: <organization>
-    user: <user>
-    key: <key>
-
-The user and org fields uniquely identify a user.
-
-The key field is generated when a new server account is set up.
-It is a shared secret, equivalent to a password, and should be protected.
-
-Authentication failure can result in these errors:
-
--   430 Authentication failed
--   431 Account suspended
-
-
-## Status Data
-
-Every response from the Taskserver SHALL contain status data:
-
-    code: <code>
-    status: <status text>
-
-The code is a numeric status indicator defined in the [Sync Protocol](/docs/design/protocol).
-
-
-## Payload Data
-
-Payload data is optional, arbitrary and message type dependent.
-It is always UTF8-encoded text.
-
-
-## Message Types
-
-The Taskserver supports several message types, thus providing a set of primitives for use by clients.
-
-It is expected that the number of supported ticket types will increase over time.
-
-
-## Sync Message
-
-The "sync" message always originates from the client, but the response will contain data from the server.
-A sync is therefore a single request with a single response.
-
-The "sync" message type MUST contain the following headers:
-
--   type
--   org
--   user
--   key
--   client
--   protocol
-
-The "sync" message payload has this format:
-
-    <uuid>
-    <JSON task 1>
-    <JSON task 2>
-    ...
-    <JSON task N>
-
-Here is an example of a sync message:
-
-    <size>type: sync
-    org: <organization>
-    user: <user>
-    key: <key>
-    client: task 2.3.0
-    protocol: v1
-
-    2e4685f8-34bc-4f9b-b7ed-399388e182e1
-    {"description":"Test data","entry":"20130602T002341Z","status":"pending"}
-
-The request contains the proper auth section, and the body contains the current sync key followed by a newline characters (U+000D), then a list of JSON-formatted tasks \[2\] each separated by a newline character (U+000D).
-
-An example response message might be:
-
-    <size>type: response
-    client: taskd 1.0.0
-    protocol: v1
-    code: 200
-    status: Ok
-
-    45da7110-1bcc-4318-d33e-12267a774e0f
-
-The status indicates success, and the payload contains zero remote task modifications, followed by a sync key.
-
-
-## Statistics Message
-
-The message format іs simply:
-
-    <size>type: statistics
-    org: <Organization>
-    user: <User>
-    key: <Key>
-    client: taskd 1.0.0
-    protocol: v1
-
-There is no payload.
-An example response message might be:
-
-    <size>type: response
-    client: taskd 1.0.0
-    protocol: v1
-    code: 200
-    status: Ok
-    average request bytes: 0
-    average response bytes: 0
-    average response time: 0.000000
-    errors: 0
-    idle: 1.000000
-    maximum response time: 0.000000
-    total bytes in: 0
-    total bytes out: 0
-    tps: 0.000000
-    transactions: 1
-    uptime: 28
-
-There is no payload, and the results are in the header variables.
-
-Note that the statistics gathered by the server are growing, which means new values are occasionally added to the response message.
-Existing values will not be removed.

doc/devel/rfcs/rules.md

@@ -1,240 +0,0 @@
----
-title: "Taskwarrior - Rule System"
----
-
-## Work in Progress
-
-This design document is a work in progress, and subject to change.
-Once finalized, the feature will be scheduled for an upcoming release.
-
-
-# Rule System
-
-The rule system is a framework that supports highly configurable features, with runtime evaluation, DOM access and an internal API.
-Implementing a rule system meets the goal of shrinking and stabilizing the product core, while adding new features, and enabling many more.
-
-
-## Required Enhancements
-
-To prepare for a Rules System, various subsystems must first be enhanced:
-
--   DOM references need to be unambiguous, and will all have the `dom.` prefix.
-
--   DOM references need to be able to access any Taskwarrior data, in any
-
--   Custom reports will change from referencing `<column>[.<format>]` to simply
-    `<domref>`
-
--   RC file syntax needs to be enhanced, so support rule definitions, which are
-    multi-line blocks that are indentation-sensitive
-
--   RC file syntax will support two ways of specifying the same data:
-
-              a.b.c=...
-
-              a:
-                b:
-                  c=...
-
--   RC file syntax will allow the use of environment variables inline:
-
-              name=${TERM}
-              include ${HOME}/.taskrc_local
-
--   The `Variant` object will migrate to `libshared`
-
--   The expression evaluator `Eval` object will migrate to `libshared`
-
--   The column objects will gain a more structured base class, and will serve as
-    providers for DOM references
-
--   The 'exec' command will be able to run a rule, if the reference is correct
-
--   Taskwarrior will store state data in a new `state.data` file
-
--   `Config` object needs to use the `rat` parser, to tackle the more complex
-    syntax
-
--   The RC file will support environment variable expansion, where `${NAME}`
-    will be replaced by its corresponding value at launch time
-
-At that point, the rules system can be implemented in `libshared`, and will use a pluggable architecture to allow its integration into several projects.
-
-## DOM Enhancements
-
-DOM references will be enhanced, with many more references supported.
-All DOM references will begin with `dom.`, yielding unambiguous references.
-References will have a type.
-Types will support sub-references (`<date>.<month>`, `<tags>.<N>`, `<annotation>.<description>`), and display formats included.
-
-       dom . [<id> .] <attribute> [. <sub-reference>] . <format>
-
-       dom . 123   .  entry        . year             . yyyy
-       dom . 123   .  entry
-       dom . 123   .  tags
-       dom . 123   .  tags         . count
-       dom . 123   .  tags         . 1
-
-In addition to direct attribute access, DOM references will also support tw references beyond the current set: dom.rc.<name>
-
-       dom.cli.args
-       dom.terminal.width
-       dom.terminal.height
-       dom.system.version
-       dom.system.oѕ
-
-And will also support higher-level constructs that do not directly correlate to attributes, for example:
-
-       dom.active       Boolean indicator of any active tasks
-       dom.synced       Boolean indicator of the need to sync
-       dom.rc.path      String path of .taskrc file (or override)
-       dom.data.path    String path of data directory
-       dom.hooks.path   String path of hooks directory
-
-Finally, access to state:
-
-       dom.state.program
-       dom.state.sync.last
-       dom.state.sync.configured
-       dom.state.run.last
-       dom.state.context
-
-
-## RC Syntax Changes
-
-The current configuration system supports only two different forms of syntax:
-
-    <name> = [ <value> ]
-
-    include <file>
-
-A rule is a new form of syntax that consists of the rule keyword, a name, optional trigger, followed by indented actions in the form of API calls and flow control.
-For example:
-
-    rule myRule() on_launch:
-        # Some code here
-
-A rule definition will appear in the RC file, alongside all the existing settings.
-The rule syntax will require a blank line to terminate the rule definition, the result being that the RC file should be quite readable, although it will look like Python.
-
-
-## Hook Scripts
-
-While this functionality can also be implemented using hook scripts, rules will run in-process, and therefore do not require external interpreters to be launched every time.
-This creates the potential to run faster than a hook script.
-
-For complex processing, hook scripts will be the preferred mechanism, but as the rules system matures, rules will be made to run more quickly.
-With adequate performance, a rule will be the preferred implementation over a hook script.
-This is not expected to be the case at first.
-
-Hook scripts are not likely to be extended beyond their current form, and with greater DOM access and a growing API, rules should be able to supplant most hook script use cases.
-
-
-## Rule Triggers
-
-The set of supported rule types will include:
-
-* `on_launch` - Triggered on program launch.
-
-* `on_add` - Triggered when a task is added.
-  A context task will be provided.
-  The rule can modify the task, and approve or reject it.
-
-* `on_modify` - Triggered when a task is modified.
-  A before and after context task will be provided.
-  The rule can modify the task, and approve or reject it.
-
-* `on_exit` - Triggered on program exit.
-
-* `color` - Triggered when colors are being determined.
-
-* `virtual tag` - Defines a new virtual tag.
-
-* `format` - Triggered when an attribute needs formatting, defines are new format.
-
-More rules types will be added for more capabilities in future releases.
-
-
-## API
-
-The API is a simple set of actions that may be taken by a rule.
-
-* `debug(<string>)` - Displays the string in debug mode only and continues processing.
-
-* `warn(<string>)` - Displays the string as a warning continues processing.
-
-* `error(<string>)` - Displays the string as an error and terminates processing.
-
-* `exec(<binary> [ <args> ... ])` - Executes the external program and passes arguments to it.
-  If the program exits with non-zero status, it is treated as an error.
-
-* `return <value>` - Provides a result value for the rule, when necessary.
-
-This is a very limited set at first, and more API calls will be added to support capabilities in future releases.
-
-
-## Grammar
-
-The grammar closely tracks that of Python.
-Blocks are indented consistently.
-
-* `if <condition>: ... else: ...` - The condition is a full Algebraic expression, and supports none of the command line conveniences.
-  Terms must be combined with logical operators.
-  The condition is an expression that is evaluated and converted to a Boolean value.
-
-* `for <name> in <collection>:` - There is no native type for a collection, but there are DOM references (`tags` \...) that reference collections.
-  This provides a way to iterate.
-
-* `set <name> = <expression>` - Writes to a named type.
-  The name may be a writable DOM object (`dom...`) or temporary variable storage (`tmp...`).
-  Writing to a read-only DOM reference is an error.
-
-* `<function>([<args>])` - A function is either a rule or an API call.
-  Calling an undefined function is an error.
-
-
-## Examples
-
-Here are some example rules which illustrate the syntax and API.
-
-The replacement for the nag feature:
-
-    rule Nag(before, after) on-modify:
-      if before.urgency < tasks.max.urgency:
-        warn ‘You have more urgent tasks’
-
-      if after.status == 'completed' and before.urgency < (dom.urgency.max - 2.0):
-        warn 'You have more urgent tasks!'
-
-Correct commonly misspelled word:
-
-    rule CorrectSpelling(task) on_add:
-      set task.description = substitute(task.description, 'teh', 'the')
-
-Abbreviation expansion:
-
-    rule ExpandAbbreviation(task) on_modify:
-      set task.description = substitute(task.description, '/TW-\d+/', 'https:\/\/github.com\/GothenburgBitFactory\/taskwarrior\/issues\/\1')
-
-Warn on missing project:
-
-    rule WarnOnMissingProject(task) on_add:
-      if task.project == ‘’:
-        warn(‘Project not specified’)
-
-Color rule:
-
-    rule ColorizeDue(task) color:
-      if task.due > now:
-        if task.due < (now + 5d):
-          return dom.rc.color.due
-        else:
-          return dom.rc.color.due.later
-
-Policy:
-
-    rule policyProject(task) on_add:
-        if task.project == '':
-            if rc.default.project == '':
-                error('You must specify a project')
-            set task.project = rc.default.project

doc/devel/rfcs/sync.md

@@ -1,242 +0,0 @@
----
-title: "Taskwarrior - Taskserver Sync Algorithm"
----
-
-
-# Taskserver Sync Algorithm
-
-This document describes how task changes are merged by the Taskserver.
-It does not describe [the protocol](/docs/design/protocol) used by the Taskserver.
-
-The Taskserver merges tasks from multiple sources, resulting in conflict- free syncing of data.
-The algorithm used to achieve this is simple and effective, paralleling what SCM systems do to perform a rebase.
-
-
-## Requirements
-
-In this document, we adopt the convention discussed in Section 1.3.2 of
-[RFC1122](https://tools.ietf.org/html/rfc1122#page-16) of using the capitalized words MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, and OPTIONAL to define the significance of each particular requirement specified in this document.
-
-In brief: "MUST" (or "REQUIRED") means that the item is an absolute requirement of the specification; "SHOULD" (or "RECOMMENDED") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and "MAY" (or "OPTIONAL") means that this item is optional, and may be omitted without careful consideration.
-
-
-## Problem Definition
-
-The sync algorithm considers a single task, with multiple changes occurring in two separate locations that must be resolved.
-The two locations are the local machine and the server.
-This results in two parallel change sequences.
-
-Examples using multiple clients collapse down to the simple two-branch case because the clients are merged serially.
-
-
-## Change Sequence
-
-A sequence of changes to the same task is represented as:
-
-    T0 --> T1 --> T2
-
-Although all examples are of the two-branch variety, some involve trivial branches.
-Going through these examples will illustrate the algorithm.
-First the legend:
-
-    T0   Represents the original task, the base.
-    T1   Represents the task with a non-trivial set of changes.
-    T2   Represents the task with further changes.
-
-
-## Deltas
-
-The transition from T0 \--\> T1 can be seen as a transform applied to T0, resulting in T1.
-That transform is the delta (d1) between T0 and T1, which is a subtractive term:
-
-    d1 = (T1 - T0)
-
-Therefore:
-
-    T0 --> T1 = T0 + d1
-              = T0 + (T1 - T0)
-
-This states that the transition from T0 to T1 is the application of a delta to the original, T0, which results in T1.
-Applying this to the whole change sequence yields:
-
-    T0 --> T1 --> T2 = T0 + d1 + d2
-                     = T0 + (T1 - T0) + (T2 - T1)
-
-
-## Use Case Classification
-
-Because clients sync requests are processed serially, there is no need to consider the multiple client cases.
-This means there is only ever the case with two parallel change sequences = the two branch case.
-
-
-## Two Branch Case
-
-The two branch case represents changes made to the same task in two locations, resulting in two deltas that must be applied to the same base.
-
-    T0 --> T1
-    T0 --> T2
-
-This reduces to a base with two deltas, but the order in which the deltas are applied is important.
-For example:
-
-    T0 + d1 + d2 =/= T0 + d2 + d1
-
-The application of deltas is not commutative, except in the trivial case where the two deltas are identical, or the deltas do not overlap.
-The deltas therefore need to be applied in the correct sequence.
-Tasks have metadata that indicates the last modified time, which dictates the sequence.
-Assuming d1 occurred before d2, this neatly collapses down to a single branch sequence:
-
-    T0 + d1 + d2 = T3
-
-Note that the result in this case is T3, because it will be neither T1 nor T2, unless the deltas are identical.
-
-
-## Two Branch, Multiple Changes Case
-
-The two branch case can be complicated by multiple changes per branch:
-
-    T0 --> T1 --> T3 --> T5
-    T0 --> T2 --> T4
-
-Note that the numbers were chosen to represent the order in which the changes were made.
-First a list of deltas is generated:
-
-    T0 --> T1 = d1
-    T1 --> T3 = d3
-    T3 --> T5 = d5
-    T0 --> T2 = d2
-    T0 --> T4 = d4
-
-    d1, d3, d5, d2, d4
-
-Then the deltas are sorted by modified time:
-
-    d1, d2, d3, d4, d5
-
-Then epplied to the base, yielding T6:
-
-    T0 + d1 + d2 + d3 + d4 +d5 = T6
-
-
-## Two Branch Case Example
-
-Suppose the base task looks like this:
-
-    T0  project:ONE  due:tomorrow  priority:H  +tag1  Original description
-
-The first branch looks like this:
-
-    T1  project:TWO  due:23rd      priority:H  +tag1  Original description
-
-The second branch looks like this:
-
-    T2  project:ONE  due:tomorrow  priority:H  +tag1  Modified description
-
-Delta d1 is:
-
-    T0  project:ONE  due:tomorrow  priority:H  +tag1  Original description
-    T1  project:TWO  due:23rd      priority:H  +tag1  Original description
-    ----------------------------------------------------------------------
-    d1  project:TWO  due:23rd
-
-Delta d2 is:
-
-    T0  project:ONE  due:tomorrow  priority:H  +tag1  Original description
-    T2  project:ONE  due:tomorrow  priority:H  +tag1  Modified description
-    ----------------------------------------------------------------------
-    d2                                                Modified description
-
-If d1 occurred before d2, the result is:
-
-    T3 = T0 + d1 + d2
-       = T0 + (project:TWO due:23rd) + (Modified description)
-
-    T3 =  project:TWO  due:23rd  priority:H  +tag1  Modified description
-
-
-## Use Cases
-
-A range of illustrated use cases, from the trivial to the complex will show the algorithm in use.
-
-
-## Use Case 1: New Local Task
-
-Initial state:
-
-    Server:  -
-    Client:  T0
-
-The server has no data, and so T0 is stored.
-The result is now:
-
-    Server:  T0
-    Client:  T0
-
-
-## Use Case 2: Local Change
-
-Initial state:
-
-    Server:  T0
-    Client:  T0 --> T1
-
-The server resolves the change:
-
-    T0 --> T1 = T0 + d1
-              = T1
-
-T1 is stored.
-The result is now:
-
-    Server:  T0 --> T1
-    Client:  T1
-
-
-## Use Case 3: Local and Remote Change
-
-Initial state:
-
-    Server:  T0 --> T1
-    Client:  T0 --> T2
-
-This is the two branch case, and the deltas are generated:
-
-    T0 --> T1 = T0 + d1
-    T0 --> T2 = T0 + d2
-
-The order of change is determine to be d1, d2, yielding T3:
-
-    T3 = T0 + d1 + d2
-
-T3 is stored on the server, and returned to the client.
-The result is now:
-
-    Server:  T0 --> T1 --> T2 --> T3
-    Client:  T3
-
-
-## Use Case 4: Multiple Local and Remote Changes
-
-Initial state:
-
-    Server:  T0 --> T1 --> T3
-    Client:  T0 --> T2 --> T4
-
-This is the two branch case, and the deltas are generated:
-
-    T0 --> T1 = T0 + d1
-    T1 --> T3 = T0 + d3
-    T0 --> T2 = T0 + d2
-    T2 --> T4 = T0 + d4
-
-    d1, d3, d2, d4
-
-The order of change is determine to be d1, d2, d3, d4, yielding T5:
-
-    T5 = T0 + d1 + d2 + d3 + d4
-
-T5 is stored on the server, and returned to the client.
-The result is now:
-
-    Server:  T0 --> T1 --> T2 --> T3 --> T4 --> T5
-    Client:  T5

doc/devel/rfcs/task.md

@@ -1,468 +0,0 @@
----
-title: "Taskwarrior - Taskwarrior JSON Format"
----
-
-
-# Taskwarrior JSON Format
-
-When Taskwarrior exchanges data, it uses [JSON](https://www.json.org/).
-This document describes the structure and semantics for tasks exported from Taskwarrior, imported to Taskwarrior, or synced with the Taskserver.
-
-Any client of the Taskserver will need to communicate task information.
-This document describes the format of a single task.
-It does not describe the communication and sync protocol between client and server.
-
-This document is subject to change.
-The data attributes are also subject to change.
-
-
-## Requirements
-
-In this document, we adopt the convention discussed in Section 1.3.2 of [RFC1122](https://tools.ietf.org/html/rfc1122#page-16) of using the capitalized words MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, and OPTIONAL to define the significance of each particular requirement specified in this document.
-
-In brief: "MUST" (or "REQUIRED") means that the item is an absolute requirement of the specification; "SHOULD" (or "RECOMMENDED") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and "MAY" (or "OPTIONAL") means that this item is optional, and may be omitted without careful consideration.
-
-
-## General Format
-
-The format is JSON, specifically a JSON object as a single line of text, terminated by a newline (U+000D).
-
-The JSON looks like this:
-
-    {"description":"One two three","status":"pending", ... }
-
-While this is not a valid task (there are missing fields), the format is illustrated.
-
-All attribute names are quoted with " (U+0022).
-A name will always have a corresponding value, and if a value is blank, then the name/value pair is omitted from the line.
-Newline characters are not permitted within the value, meaning that a task consists of a single line of text.
-
-All data is UTF8.
-
-
-## Data Types
-
-There are five data types used in the task format.
-
-
-## Data Type: String
-
-Strings may consist of any UTF8 encoded characters.
-
-
-## Data Type: Fixed String
-
-A fixed string is one value from a set of acceptable values, such as a priority level, where the values may only be "", "L", "M" or "H".
-
-
-## Data Type: UUID
-
-A UUID is a 32-hex-character lower case string, formatted in this way:
-
-    xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
-
-An example:
-
-    296d835e-8f85-4224-8f36-c612cad1b9f8
-
-
-## Data Type: Integer
-
-Integers are rendered in a simple fashion:
-
-    123
-
-
-## Data Type: Date
-
-Dates are rendered in ISO 8601 combined date and time in UTC format using the template:
-
-    YYYYMMDDTHHMMSSZ
-
-An example:
-
-    20120110T231200Z
-
-No other formats are supported.
-
-
-## Data Type: Duration
-
-Duration values represent a time period.
-They take the form:
-
-    [[<sign>] <number>] <unit>
-
-Some examples include:
-
--   -3days
--   annual
--   4hrs
-
-The supported units are:
-
--   annual
--   biannual
--   bimonthly
--   biweekly
--   biyearly
--   daily
--   days
--   day
--   d
--   fortnight
--   hours
--   hour
--   hrs
--   hr
--   h
--   minutes
--   mins
--   min
--   monthly
--   months
--   month
--   mnths
--   mths
--   mth
--   mos
--   mo
--   quarterly
--   quarters
--   qrtrs
--   qtrs
--   qtr
--   q
--   seconds
--   secs
--   sec
--   s
--   semiannual
--   sennight
--   weekdays
--   weekly
--   weeks
--   week
--   wks
--   wk
--   w
--   yearly
--   years
--   year
--   yrs
--   yr
--   y
-
-Note that some values lack precision, for example "2q" means two quarters, or half a year.
-
-Note that not all combinations of number and unit make sense, for example "3annual" makes no sense, but evaluates to "3years".
-
-
-## The Attributes
-
-Here are the standard attributes that may comprise a task:
-
-| Name         | Type    |
-|--------------|---------|
-| status       | String  |
-| uuid         | UUID    |
-| entry        | Date    |
-| description  | String  |
-| start        | Date    |
-| end          | Date    |
-| due          | Date    |
-| until        | Date    |
-| wait         | Date    |
-| modified     | Date    |
-| scheduled    | Date    |
-| recur        | String  |
-| mask         | String  |
-| imask        | Integer |
-| parent       | UUID    |
-| project      | String  |
-| priority     | String  |
-| depends      | String  |
-| tags *       | String  |
-| annotation * | String  |
-| (UDA)        | ?       |
-
-\* Both tags and annotations are lists of strings and objects.
-
-Any UDA fields are assumed to be of type string.
-
-There are other forms, which are conditional upon the state of a task:
-
-| Status Value | Pending | Deleted | Completed | Waiting | Recurring Parent | Recurring Child |
-|--------------|---------|---------|-----------|---------|------------------|-----------------|
-| status       | Reqd    | Reqd    | Reqd      | Reqd    | Reqd             | Reqd            |
-| uuid         | Reqd    | Reqd    | Reqd      | Reqd    | Reqd             | Reqd            |
-| entry        | Reqd    | Reqd    | Reqd      | Reqd    | Reqd             | Reqd            |
-| description  | Reqd    | Reqd    | Reqd      | Reqd    | Reqd             | Reqd            |
-| start        | Opt     | Opt     | Opt       | Opt     | Opt              | Opt             |
-| end          |         | Reqd    | Reqd      |         |                  |                 |
-| due          | Opt     | Opt     | Opt       | Opt     | Reqd             | Opt             |
-| until        | Opt     | Opt     | Opt       | Opt     | Opt              | Opt             |
-| scheduled    | Opt     | Opt     | Opt       | Opt     | Opt              | Opt             |
-| wait         |         |         |           | Reqd    |                  |                 |
-| recur        |         |         |           |         | Reqd             | Reqd            |
-| mask         |         |         |           |         | Intrn            |                 |
-| imask        |         |         |           |         |                  | Intrn           |
-| parent       |         |         |           |         |                  | Reqd            |
-| annotation   | Opt     | Opt     | Opt       | Opt     | Opt              | Opt             |
-| project      | Opt     | Opt     | Opt       | Opt     | Opt              | Opt             |
-| tags         | Opt     | Opt     | Opt       | Opt     | Opt              | Opt             |
-| priority     | Opt     | Opt     | Opt       | Opt     | Opt              | Opt             |
-| depends      | Opt     | Opt     | Opt       | Opt     | Opt              | Opt             |
-| modified     | Intrn   | Intrn   | Intrn     | Intrn   | Intrn            | Intrn           |
-| UDA          | Opt     | Opt     | Opt       | Opt     | Opt              | Opt             |
-
-(Legend: Reqd = required, Opt = optional, Intrn = Internally generated)
-
-All tasks have four required fields.
-There are other states in which a task may exist, and the requirements change.
-At a minimum, a valid task contains:
-
--   uuid
--   status
--   entry
--   description
-
-*Deleted* - A deleted task MUST also have "status":"deleted", an "end" date and a "modified" date.
-
-*Completed* - A completed task MUST also have "status":"completed", an "end" date and a "modified" date.
-
-*Waiting* - A waiting task MUST also have "status":"waiting" and a "wait" date.
-The task is hidden from the user, until that "wait" date has passed, whereupon the status reverts to "pending", and the "wait" date is removed.
-
-*Recurring Parent* - When a recurring task is entered, it MUST have "status":"recurring", a "recur" period and a "due" date.
-It MAY also have an "until" date.
-Recurring parent tasks are hidden from the user.
-
-*Recurring Child* - A recurring child task is not created by the user, but is cloned from the recurring parent task by the Taskserver.
-It may be modified by the user.
-On completion, there is special handling to be done.
-See section 3.11.
-
-
-## Additional Attributes
-
-There MAY be other fields than those listed above in a task definition.
-Such fields MUST be preserved intact by any client, which means that if a task is downloaded that contains an unrecognized field, that field MUST not be modified, and MUST continue to exist in the task..
-
-User Defined Attributes (UDAs) are additional fields.
-
-
-## Attribute Details
-
-The individual fields convey important information about a task, and in some cases work only in collusion with other fields.
-All such details are listed here.
-
-
-## Attribute: status
-
-The status field describes the state of the task, which may ONLY be one of these literal strings:
-
-    "status":"pending"
-    "status":"deleted"
-    "status":"completed"
-    "status":"waiting"
-    "status":"recurring"
-
-A pending task is a task that has not yet been completed or deleted.
-This is the typical state for a task.
-
-A deleted task is one that has been removed from the pending state, and MUST have an "end" field specified.
-Given the required "entry" and "end" field, it can be determined how long the task was pending.
-
-A completed task is one that has been removed from the pending state by completion, and MUST have an "end" field specified.
-Given the required "entry" and "end" fields, it can be determine how long the task was pending.
-
-A waiting task is ostensibly a pending task that has been hidden from typical view, and MUST have a "wait" field containing the date when the task is automatically returned to the pending state.
-If a client sees a task that is in the waiting state, and the "wait" field is earlier than the current date and time, the client MUST remove the "wait" field and set the "status" field to "pending".
-
-A recurring task is essentially a parent template task from which child tasks are cloned.
-The parent remains hidden from view, and contains a "mask" field that represents the recurrences.
-Each cloned child task has an "imask" field that indexes into the parent "mask" field, as well as a "parent" field that lists the UUID of the parent.
-
-
-## Attribute: uuid
-
-When a task is created, it MUST be assigned a new UUID by the client.
-Once assigned, a UUID field MUST NOT be modified.
-UUID fields are permanent.
-
-
-## Attribute: entry
-
-When a task is created, it MUST be assigned an "entry" date by the client.
-This is the creation date of the task.
-
-
-## Attribute: description
-
-When a task is created, it MUST have a "description" field value, which contains UTF8 characters.
-A "description" field may not contain newline characters, but may contain other characters, properly escaped.
-See <https://json.org> for details.
-
-
-## Attribute: start
-
-To indicate that a task is being worked on, it MAY be assigned a "start" field.
-Such a task is then considered Active.
-
-
-## Attribute: end
-
-When a task is deleted or completed, is MUST be assigned an "end" field.
-It is not valid for a task to have an "end" field unless the status is also "completed" or "deleted".
-If a completed task is restored to the "pending" state, the "end" field is removed.
-
-
-## Attribute: due
-
-A task MAY have a "due" field, which indicates when the task should be completed.
-
-
-## Attribute: until
-
-A recurring task MAY have an "until" field, which is the date after which no more recurring tasks should be generated.
-At that time, the parent recurring task is set to "completed".
-
-
-## Attribute: wait
-
-A task MAY have a "wait" field date, in conjunction with a "status" of "waiting".
-A waiting task is one that is not typically shown on reports until it is past the wait date.
-
-An example of this is a birthday reminder.
-A task may be entered for a birthday reminder in 10 months time, but can have a "wait" date 9 months from now, which means the task remains hidden until 1 month before the due date.
-This prevents long-term tasks from cluttering reports until they become relevant.
-
-
-## Attribute: recur
-
-The "recur" field is for recurring tasks, and specifies the period between child tasks, in the form of a duration value.
-The value is kept in the raw state (such as "3wks") as a string, so that it may be evaluated each time it is needed.
-
-
-## Attribute: mask
-
-A parent recurring task has a "mask" field that is an array of child status indicators.
-Suppose a task is created that is due every week for a month.
-The "mask" field will look like:
-
-    "----"
-
-This mask has four slots, indicating that there are four child tasks, and each slot indicates, in this case, that the child tasks are pending ("-").
-The possible slot indicators are:
-
-* `-` - Pending
-* `+` - Completed
-* `X` - Deleted
-* `W` - Waiting
-
-Suppose the first three tasks has been completed, the mask would look like this:
-
-    "+++-"
-
-If there were only three indicators in the mask:
-
-    "+-+"
-
-This would indicate that the second task is pending, the first and third are complete, and the fourth has not yet been generated.
-
-
-## Attribute: imask
-
-Child recurring tasks have an "imask" field instead of a "mask" field like their parent.
-The "imask" field is a zero-based integer offset into the "mask" field of the parent.
-
-If a child task is completed, one of the changes that MUST occur is to look up the parent task, and using "imask" set the "mask" of the parent to the correct indicator.
-This prevents recurring tasks from being generated twice.
-
-
-## Attribute: parent
-
-A recurring task instance MUST have a "parent" field, which is the UUID of the task that has "status" of "recurring".
-This linkage between tasks, established using "parent", "mask" and "imask" is used to track the need to generate more recurring tasks.
-
-
-## Attribute: annotation\_\...
-
-Annotations are strings with timestamps.
-Each annotation itself has an "entry" field and a "description" field, similar to the task itself.
-Annotations form an array named "annotations".
-For example (lines broken for clarity):
-
-    "annotations":[
-      {"entry":"20120110T234212Z","description":"Remember to get the mail"},
-      {"entry":"20120110T234559Z","description":"Pay the bills"}
-    ]
-
-
-## Attribute: project
-
-A project is a single string.
-For example:
-
-    "project":"Personal Taxes"
-
-Note that projects receive special handling, so that when a "." (U+002E) is used, it implies a hierarchy, which means the following two projects:
-
-    "Home.Kitchen"
-    "Home.Garden"
-
-are both considered part of the "Home" project.
-
-
-## Attribute: tags
-
-The "tags" field is an array of string, where each string is a single word containing no spaces.
-For example:
-
-    "tags":["home","garden"]
-
-
-## Attribute: priority
-
-The "priority" field, if present, MAY contain one of the following strings:
-
-    "priority":"H"
-    "priority":"M"
-    "priority":"L"
-
-These represent High, Medium and Low priorities.
-An absent priority field indicates no priority.
-
-
-## Attribute: depends
-
-The "depends" field is a string containing a comma-separated unique set of UUIDs.
-If task 2 depends on task 1, then it is task 1 that must be completed first.
-Task 1 is considered a "blocking" tasks, and task 2 is considered a "blocked" task.
-For example:
-
-    "depends":",, ..."
-
-Note that in a future version of this specification, this will be changed to a JSON array of strings, like the "tags" field.
-
-
-## Attribute: modified
-
-A task MUST have a "modified" field set if it is modified.
-This field is of type "date", and is used as a reference when merging tasks.
-
-
-## Attribute: scheduled
-
-A task MAY have a "scheduled" field, which indicates when the task should be available to start.
-A task that has passed its "scheduled" data is said to be "ready".
-
-
-## User Defined Attributes
-
-A User Defined Attribute (UDA) is a field that is defined via configuration.
-Given that the configuration is not present in the JSON format of a task, any fields that are not recognized are to be treated as UDAs.
-This means that if a task contains a UDA, unless the meaning of it is understood, it MUST be preserved.
-
-UDAs may have one of four types: string, numeric, date and duration.

doc/devel/rfcs/workweek.md

@@ -1,29 +0,0 @@
----
-title: "Taskwarrior - Work Week Support"
----
-
-## Work in Progress
-
-This design document is a work in progress, and subject to change.
-Once finalized, the feature will be scheduled for an upcoming release.
-
-
-# Work Week Support
-
-Taskwarrior supports the idea that a week starts on either a Sunday or a Monday, as determined by configuration.
-This was added eight years ago, simply for display purposes in the `calendar` report.
-Since then its use has propagated and it influences the `sow` date reference.0
-
-Further requests have been made to make this more flexible, so that the notion of 'weekend' can be defined.
-Furthermore, the idea that every week has a weekend has also been questioned.
-
-It has become clear that a `weekstart` setting, and the notion of a weekend are no longer useful.
-
-## Proposed Support
-
-One option is to allow the user to completely define a work week in the following way:
-
-    workweek=1,2,3,4,5
-
-With Sunday as day zero, this states that the work week is the typical Monday - Friday.
-From this setting, the meaning of `soww` and `eoww` can be determined, as well as `recur:weekday`.

doc/man/.gitignore

@@ -0,0 +1,4 @@
+task-color.5
+task-sync.5
+task.1
+taskrc.5

doc/man/task-color.5.in

@@ -8,18 +8,14 @@ It should be mentioned that Taskwarrior is aware of whether its output is going
 to a terminal, or to a file or through a pipe.  When Taskwarrior output goes to
 a terminal, color is desirable, but consider the following command:
 
-.nf
     $ task list > file.txt
-.fi
 
 Do we really want all those color control codes in the file?  Taskwarrior
 assumes that you do not, and temporarily sets color to 'off' while generating
 the output.  This explains the output from the following command:
 
-.nf
     $ task show | grep '^color '
     color                        off
-.fi
 
 it always returns 'off', no matter what the setting, because the output is being
 sent to a pipe.
@@ -27,26 +23,20 @@ sent to a pipe.
 If you wanted those color codes, you can override this behavior by setting the
 _forcecolor variable to on, like this:
 
-.nf
     $ task config _forcecolor on
     $ task config | grep '^color '
     color                        on
-.fi
 
 or by temporarily overriding it like this:
 
-.nf
     $ task rc._forcecolor=on config | grep '^color '
     color                        on
-.fi
 
 .SH AVAILABLE COLORS
 Taskwarrior has a 'color' command that will show all the colors it is capable of
 displaying.  Try this:
 
-.nf
     $ task color
-.fi
 
 The output cannot be replicated here in a man page, but you should see a set of
 color samples.  How many you see depends on your terminal program's ability to
@@ -58,9 +48,7 @@ You should at least see the Basic colors and Effects - if you do, then you have
 .SH 16-COLOR SUPPORT
 The basic color support is provided through named colors:
 
-.nf
     black, red, blue, green, magenta, cyan, yellow, white
-.fi
 
 Foreground color (for text) is simply specified as one of the above colors, or
 not specified at all to use the default terminal text color.
@@ -68,49 +56,37 @@ not specified at all to use the default terminal text color.
 Background color is specified by using the word 'on', and one of the above
 colors.  Some examples:
 
-.nf
     green                 # green text, default background color
     green on yellow       # green text, yellow background
     on yellow             # default text color, yellow background
-.fi
 
 These colors can be modified further, by making the foreground bold, or by
 making the background bright.  Some examples:
 
-.nf
     bold green
     bold white on bright red
     on bright cyan
-.fi
 
 The order of the words is not important, so the following are equivalent:
 
-.nf
     bold green
     green bold
-.fi
 
 But the 'on' is important - colors before the 'on' are foreground, and colors
 after 'on' are background.
 
 There is an additional 'underline' attribute that may be used:
 
-.nf
     underline bold red on black
-.fi
 
 And an 'inverse' attribute:
 
-.nf
     inverse red
-.fi
 
 Taskwarrior has a command that helps you visualize these color combinations.
 Try this:
 
-.nf
     $ task color underline bold red on black
-.fi
 
 You can use this command to see how the various color combinations work.  You
 will also see some sample colors displayed, like the ones above, in addition to
@@ -127,13 +103,11 @@ Using 256 colors follows the same form, but the names are different, and some
 colors can be referenced in different ways.  First there is by color ordinal,
 which is like this:
 
-.nf
     color0
     color1
     color2
     ...
     color255
-.fi
 
 This gives you access to all 256 colors, but doesn't help you much.  This range
 is a combination of 8 basic colors (color0 - color7), then 8 brighter variations
@@ -145,43 +119,31 @@ be addressed via RGB values from 0 to 5 for each component color.  A value of 0
 means none of this component color, and a value of 5 means the most intense
 component color.  For example, a bright red is specified as:
 
-.nf
     rgb500
-.fi
 
 And a darker red would be:
 
-.nf
     rgb300
-.fi
 
 Note that the three digits represent the three component values, so in this
 example the 5, 0 and 0 represent red=5, green=0, blue=0.  Combining intense red
 with no green and no blue yields red.  Similarly, blue and green are:
 
-.nf
     rgb005
     rgb050
-.fi
 
 Another example - bright yellow - is a mix of bright red and bright green, but
 no blue component, so bright yellow is addressed as:
 
-.nf
     rgb550
-.fi
 
 A soft pink would be addressed as:
 
-.nf
     rgb515
-.fi
 
 See if you agree, by running:
 
-.nf
     $ task color black on rgb515
-.fi
 
 You may notice that the large color block is represented as 6 squares.  All
 colors in the first square have a red value of 0.  All colors in the 6th square
@@ -201,9 +163,7 @@ will be disappointed, perhaps even appalled.
 There is some limited color mapping - for example, if you were to specify this
 combination:
 
-.nf
     red on gray3
-.fi
 
 you are mixing a 16-color and 256-color specification.  Taskwarrior will map red
 to color1, and proceed.  Note that red and color1 are not quite the same tone.
@@ -215,9 +175,7 @@ colors, but there is still underline available.
 Taskwarrior will show examples of all defined colors used in your .taskrc, or
 theme, if you run this command:
 
-.nf
     $ task color legend
-.fi
 
 This gives you an example of each of the colors, so you can see the effect,
 without necessarily creating a set of tasks that meet each of the rule criteria.
@@ -227,26 +185,20 @@ Taskwarrior supports colorization rules.  These are configuration values that
 specify a color, and the conditions under which that color is used.  By example,
 let us add a few tasks:
 
-.nf
     $ task add project:Home priority:H pay the bills               (1)
     $ task add project:Home            clean the rug               (2)
     $ task add project:Garden          clean out the garage        (3)
-.fi
 
 We can add a color rule that uses a blue background for all tasks in the Home
 project:
 
-.nf
     $ task config color.project.Home 'on blue'
-.fi
 
 We use quotes around 'on blue' because there are two words, but they represent
 one value in the .taskrc file.  Now suppose we wish to use a bold yellow text
 color for all cleaning work:
 
-.nf
     $ task config color.keyword.clean 'bold yellow'
-.fi
 
 Now what happens to task 2, which belongs to project Home (blue background), and
 is also a cleaning task (bold yellow foreground)?  The colors are combined, and
@@ -267,9 +219,7 @@ color blending.
 The precedence for the color rules is determined by the configuration
 variable 'rule.precedence.color', which by default contains:
 
-.nf
     deleted,completed,active,keyword.,tag.,project.,overdue,scheduled,due.today,due,blocked,blocking,recurring,tagged,uda.
-.fi
 
 These are just the color rules with the 'color.' prefix removed.  The
 rule 'color.deleted' has the highest precedence, and 'color.uda.' the lowest.
@@ -278,7 +228,7 @@ The keyword rule shown here as 'keyword.' corresponds to a wildcard pattern,
 meaning 'color.keyword.*', or in other words all the keyword rules.
 
 There is also 'color.project.none', 'color.tag.none' and
-\[aq]color.uda.priority.none' to specifically represent missing data.
+'color.uda.priority.none' to specifically represent missing data.
 
 .SH THEMES
 Taskwarrior supports themes.  What this really means is that with the ability to
@@ -288,38 +238,50 @@ be included.
 To get a good idea of what a color theme looks like, try adding this entry to
 your .taskrc file:
 
-.nf
-    include dark-256.theme
-.fi
+.RS
+include dark-256.theme
+.RE
 
 You can use any of the standard Taskwarrior themes:
 
-.nf
-    dark-16.theme
-    dark-256.theme
-    dark-blue-256.theme
-    dark-gray-256.theme
-    dark-green-256.theme
-    dark-red-256.theme
-    dark-violets-256.theme
-    dark-yellow-green.theme
-    light-16.theme
-    light-256.theme
-    solarized-dark-256.theme
-    solarized-light-256.theme
-    dark-default-16.theme
-    dark-gray-blue-256.theme
-    no-color.theme
-.fi
+.RS
+dark-16.theme
+.br
+dark-256.theme
+.br
+dark-blue-256.theme
+.br
+dark-gray-256.theme
+.br
+dark-green-256.theme
+.br
+dark-red-256.theme
+.br
+dark-violets-256.theme
+.br
+dark-yellow-green.theme
+.br
+light-16.theme
+.br
+light-256.theme
+.br
+solarized-dark-256.theme
+.br
+solarized-light-256.theme
+.br
+dark-default-16.theme
+.br
+dark-gray-blue-256.theme
+.br
+no-color.theme
+.RE
 
 Bear in mind that if you are using a terminal with a dark background, you will
 see better results using a dark theme.
 
 You can also see how the theme will color the various tasks with the command:
 
-.nf
     $ task color legend
-.fi
 
 Better yet, create your own, and share it.  We will gladly host the theme file
 on <https://taskwarrior.org>.

doc/man/task-sync.5.in

@@ -1,272 +1,51 @@
 .TH task-sync 5 2016-02-24 "${PACKAGE_STRING}" "User Manuals"
 
 .SH NAME
-task-sync \- A discussion and tutorial for the various
-.BR task (1)
-data synchronization capabilities.
+task-sync \- A discussion and tutorial for the various task(1) data
+synchronization capabilities.
 
 .SH INTRODUCTION
+Taskwarrior has several sync options, both external and built in.  If you wish
+to sync your data, choose one method only; mixing methods is going to lead to
+problems.  Each of the methods discussed have their own strengths.
 
-Taskwarrior can synchronize your tasks to a server. This has a few benefits:
+.SH ALTERNATIVES
+There are three alternatives for syncing data, which are:
+
+1) Version control systems, such as git, hg, svn
 .br
-  - Makes your tasks accessible from multiple systems, called "replicas".
+2) File sharing systems, such as DropBox, Google Drive
 .br
-  - Provides a backup of your tasks.
+3) Using the Taskserver and the 'sync' command
+
+
+.SH OPTION 1: VERSION CONTROL SYSTEMS
+There are several good, distributed VCS systems (git, hg, ...) and centralized
+VCS systems (svn, cvs ...), and they all function in a similar fashion for our
+purposes.
+
+Setup is straightforward.  You place your .task directory under revision
+control.  You then need to perform a regular commit/push/pull/update to make
+sure that the data is propagated when needed.  You can even do this using shell
+scripts so that every task command is preceded by a 'pull' and followed by
+a 'push'.
+
+Strengths:
 .br
-  - Saves disk space.
-
-For example, you might want a replica of your tasks on your laptop and on your phone.
-
-NOTE: A side-effect of synchronization is that once changes have been
-synchronized, they cannot be undone. This means that each time synchronization
-is run, it is no longer possible to undo previous operations.
-
-.SH MANAGING SYNCHRONIZATION
-
-.SS Adding a Replica
-
-To add a new replica, configure a new, empty replica identically to
-the existing replica, and run `task sync`.
-
-.SS When to Synchronize
-
-For synchronization to a server, a common solution is to run
-
-.nf
-    $ task sync
-.fi
-
-periodically, such as via
-.BR cron (8) .
-
-.SH CONFIGURATION
-
-Taskwarrior provides several options for synchronizing your tasks:
-
- - To a server specifically designed to handle Taskwarrior data.
- + To a cloud storage provider. Currently only GCP is supported.
- - To a local, on-disk file.
-
-For most of these, you will need an encryption secret used to encrypt and
-decrypt your tasks. This can be any secret string, and must match for all
-replicas sharing tasks.
-
-.nf
-    $ task config sync.encryption_secret <encryption_secret>
-.fi
-
-Tools such as
-.BR pwgen (1)
-can generate suitable secret values.
-
-.SS Sync Server
-
-To synchronize your tasks to a sync server, you will need the following
-information from the server administrator:
-
+  - Good data transport mechanisms
 .br
-  - The server's URL (such as "https://tw.example.com/path")
+  - Secure transport options
+
+Weaknesses:
 .br
-  - A client ID ("client_id") identifying your tasks
+  - You need proficiency with VCS tools
+.br
+  - You will need to manually resolve conflicts frequently
+.br
+  - You need to provide the mechanism for making sure copies are up to date
 
-Configure Taskwarrior with these details:
-
-.nf
-    $ task config sync.server.url               <url>
-    $ task config sync.server.client_id         <client_id>
-.fi
-
-Note that the URL must include the scheme, such as 'http://' or 'https://'.
-
-    $ task config sync.server.origin            <origin>
-
-Is a deprecated synonym for "sync.server.url".
-
-.SS Google Cloud Platform
-
-To synchronize your tasks to GCP, use the GCP Console to create a new project,
-and within that project a new Cloud Storage bucket. The default settings for
-the bucket are adequate.
-
-Authenticate to the project with:
-
-.nf
-    $ gcloud config set project $PROJECT_NAME
-    $ gcloud auth application-default login
-.fi
-
-Then configure Taskwarrior with:
-
-.nf
-    $ task config sync.gcp.bucket               <bucket-name>
-.fi
-
-However you can bring your own service account credentials if your
-`application-default` is already being used by some other application
-
-To begin, navigate to the "IAM and Admin" section in the Navigation Menu, then select "Roles."
-
-On the top menu bar within the "Roles" section, click "CREATE ROLE."
-Provide an appropriate name and description for the new role.
-
-Add permissions to your new role using the filter "Service:storage" (not the "Filter permissions by role" input box).
-Select the following permissions:
-
-    - storage.buckets.create
-    - storage.buckets.get
-    - storage.buckets.update
-    - storage.objects.create
-    - storage.objects.delete
-    - storage.objects.get
-    - storage.objects.list
-    - storage.objects.update
-
-Create your new role.
-
-On the left sidebar, navigate to "Service accounts."
-
-On the top menu bar within the "Service accounts" section, click "CREATE SERVICE ACCOUNT."
-Provide an appropriate name and description for the new service account.
-Select the role you just created and complete the service account creation process.
-
-Now, in the Service Account dashboard, click into the new service account and select "keys" on the top menu bar.
-Click on "ADD KEY" to create and download a new key (a JSON key).
-
-Then configure Taskwarrior with:
-
-.nf
-    $ task config sync.gcp.bucket               <bucket-name>
-    $ task config sync.gcp.credential_path      <absolute-path-to-downloaded-credentials>
-.fi
-
-.SS Amazon Web Services
-
-To synchronize your tasks to AWS, select a region near you and use the AWS
-console to create a new S3 bucket. The default settings for the bucket are
-adequate.
-
-You will also need an AWS IAM user with the following policy, where BUCKETNAME
-is the name of the bucket. The same user can be configured for multiple
-Taskwarrior clients.
-
-.nf
-    {
-        "Version": "2012-10-17",
-        "Statement": [
-            {
-                "Sid": "TaskChampion",
-                "Effect": "Allow",
-                "Action": [
-                    "s3:PutObject",
-                    "s3:GetObject",
-                    "s3:ListBucket",
-                    "s3:DeleteObject"
-                ],
-                "Resource": [
-                    "arn:aws:s3:::BUCKETNAME",
-                    "arn:aws:s3:::BUCKETNAME/*"
-                ]
-            }
-        ]
-    }
-.fi
-
-To create such a user, create a new policy in the IAM console, select the JSON
-option in the policy editor, and paste the policy. Click "Next" and give the
-policy a name such as "TaskwarriorSync". Next, create a new user, with a name
-of your choosing, select "Attach Policies Directly", and then choose the
-newly-created policy.
-
-You will need access keys configured for the new user. Find the user in the
-user list, open the "Security Credentials" tab, then click "Create access key"
-and follow the steps.
-
-At this point, you can choose how to provide those credentials to Taskwarrior.
-The simplest is to include them in the Taskwarrior configuration:
-
-.nf
-    $ task config sync.aws.region              <region>
-    $ task config sync.aws.bucket              <bucket-name>
-    $ task config sync.aws.access_key_id       <access-key-id>
-    $ task config sync.aws.secret_access_key   <secret-access-key>
-.fi
-
-Alternatively, you can set up an AWS CLI profile, using a profile name of your
-choosing such as "taskwarrior-creds":
-
-.nf
-    $ aws configure --profile taskwarrior-creds
-.fi
-
-Enter the access key ID and secret access key. The default region and format
-are not important. Then configure Taskwarrior with:
-
-.nf
-    $ task config sync.aws.region              <region>
-    $ task config sync.aws.bucket              <bucket-name>
-    $ task config sync.aws.profile             taskwarrior-creds
-.fi
-
-To use AWS's default credential sources, such as environment variables, the
-default profile, or an instance profile, set
-
-.nf
-    $ task config sync.aws.region              <region>
-    $ task config sync.aws.bucket              <bucket-name>
-    $ task config sync.aws.default_credentials true
-.fi
-
-.SS Local Synchronization
-
-In order to take advantage of synchronization's side effect of saving disk
-space without setting up a remote server, it is possible to sync tasks locally.
-To configure local sync:
-
-.nf
-    $ task config sync.local.server_dir /path/to/sync
-.fi
-
-The default configuration is to sync to a database in the task directory
-("data.location").
-
-.SH RUNNING TASKCHAMPION-SYNC-SERVER
-
-The TaskChampion sync server is an HTTP server supporting multiple users.
-Users are identified by a client ID, and users with different client IDs are
-entirely independent.  Task data is encrypted by Taskwarrior, and the sync
-server never sees un-encrypted data.
-
-The server is developed in
-https://github.com/GothenburgBitFactory/taskchampion-sync-server.
-
-.SS Adding a New User
-
-To add a new user to the server, invent a new client ID with a tool like
-`uuidgen` or an online UUID generator. There is no need to configure the server
-for this new client ID: the sync server will automatically create a new user
-whenever presented with a new client ID.  Supply the ID, along with the
-URL, to the user for inclusion in their Taskwarrior config. The user should
-invent their own "encryption_secret".
-
-.SH AVOIDING DUPLICATE RECURRING TASKS
-
-If you run multiple clients that sync to the same server, you will need to run
-this command on your primary client (the one you use most often):
-
-.nf
-    $ task config recurrence on
-.fi
-
-And on the other clients, run:
-
-.nf
-    $ task config recurrence off
-.fi
-
-This protects you against the effects of a sync/duplication bug.
-
-.SH ALTERNATIVE: FILE SHARING SERVICES
 
+.SH OPTION 2: FILE SHARING SERVICES
 There are many file sharing services, such as DropBox, Amazon S3, Google Drive,
 SkyDrive and more.  This technique involves storing your .task directory in a
 shared directory under the control of the file hosting services.
@@ -280,9 +59,7 @@ modifying the same task on two machines, without an intervening sync.
 Setup simply involves creating the directory and modifying your data.location
 configuration variable like this:
 
-.nf
     $ task config data.location /path/to/shared/directory
-.fi
 
 Strengths:
 .br
@@ -297,6 +74,78 @@ Weaknesses:
   - Tasks are not properly merged
 
 
+.SH OPTION 3: TASKSERVER
+The Taskserver was designed for this purpose to be secure, fast and conflict-
+free, allowing data interchange between assorted Taskwarrior clients, and
+tolerant of network connectivity problems.
+
+There is a 'sync' command built in to Taskwarrior (provided the GnuTLS library
+is installed), and with a server account and client configuration, syncing is
+done on demand.
+
+Setup is a matter of creating an account on a Taskserver (see your Taskserver
+provider or operate your own - see
+https://taskwarrior.org/docs/taskserver/setup.html)
+
+Once you have an account, you'll receive a certificate, key, and credentials.
+You'll need to put the certificate and key somewhere like this:
+
+    $ cp <name>.cert.pem ~/.task
+    $ cp <name>.key.pem ~/.task
+
+Then you configure Taskwarrior, using the provided details:
+
+    $ task config taskd.certificate ~/.task/<name>.cert.pem
+    $ task config taskd.key         ~/.task/<name>.key.pem
+    $ task config taskd.credentials <organization>/<name>/<UUID>
+    $ task config taskd.server      <server domain>:<port>
+
+If you are using a private server, you are likely also using a self-signed
+certificate, which means you will need one of the following additional entries:
+
+    $ task config taskd.ca          ~/.task/ca.cert.pem
+
+The CA (Certificate Authority) will be used to verify the server certificate.
+
+After setup, you run a one-time sync initialization, like this:
+
+    $ task sync init
+
+This will make sure your client and the server are properly in sync to begin
+with.  From this point on, you never run the 'initialize' command again, just
+go about your business, and when you want to sync, run this:
+
+    $ task sync
+
+You'll see a summary of how many tasks were uploaded and downloaded.  You can
+safely run the command as often as you like.  When there are no changes to sync,
+nothing happens.  If you do not have connectivity, your task changes accumulate
+so that when you next run 'sync' with proper connectivity, the changes are
+properly handled, in the right order.
+
+If you run multiple clients that sync to the same server, you will need to run
+this command on your primary client (the one you use most often):
+
+    $ task config recurrence on
+
+And on the other clients, run:
+
+    $ task config recurrence off
+
+This protects you against the effects of a sync/duplication bug.
+
+Strengths:
+.br
+  - Secure communication
+.br
+  - Minimal bandwidth
+.br
+  - Tolerates connectivity outage
+
+Weaknesses:
+.br
+  - You need to manage your own server, or gain access to a hosted server.
+
 .SH "CREDITS & COPYRIGHTS"
 Copyright (C) 2006 \- 2021 T. Babej, P. Beckingham, F. Hernandez.
 

doc/man/task.1.in

@@ -24,24 +24,18 @@ descriptors), project groups, etc.
 The <filter> consists of zero or more search criteria that select tasks.  For
 example, to list all pending tasks belonging to the 'Home' project:
 
-.nf
   task project:Home list
-.fi
 
 You can specify multiple filter terms, each of which further restricts the
 result:
 
-.nf
   task project:Home +weekend garden list
-.fi
 
 This example applies three filters: the 'Home' project, the 'weekend' tag, and
 the description or annotations must contain the character sequence 'garden'.
 In this example, 'garden' is translated internally to:
 
-.nf
   description.contains:garden
-.fi
 
 as a convenient shortcut.  The 'contains' here is an attribute modifier, which
 is used to exert more control over the filter than simply absence or presence.
@@ -51,30 +45,24 @@ Note that a filter may have zero terms, which means that all tasks apply to the
 command.  This can be dangerous, and this special case is confirmed, and
 cannot be overridden.  For example, this command:
 
-.nf
   task modify +work
   This command has no filter, and will modify all tasks.  Are you sure? (yes/no)
-.fi
 
 will add the 'work' tag to all tasks, but only after confirmation.
 
 More filter examples:
 
-.nf
   task                                      <command> <mods>
   task 28                                   <command> <mods>
   task +weekend                             <command> <mods>
   task +bills due.by:eom                    <command> <mods>
   task project:Home due.before:today        <command> <mods>
   task ebeeab00-ccf8-464b-8b58-f7f2d606edfb <command> <mods>
-.fi
 
 By default filter elements are combined with an implicit 'and' operator,
 but 'or' and 'xor' may also be used, provided parentheses are included:
 
-.nf
   task '( /[Cc]at|[Dd]og/ or /[0-9]+/ )'      <command> <mods>
-.fi
 
 The parentheses isolate the logical term from any default command filter or
 implicit report filter which would be combined with an implicit 'and'.
@@ -83,12 +71,10 @@ A filter may target specific tasks using ID or UUID numbers.  To specify
 multiple tasks use one of these forms (space-separated list of ID numbers,
 UUID numbers or ID ranges):
 
-.nf
   task 1 2 3                                    delete
   task 1-3                                      info
   task 1 2-5 19                                 modify pri:H
   task 4-7 ebeeab00-ccf8-464b-8b58-f7f2d606edfb info
-.fi
 
 Note that it may be necessary to properly escape special characters as well as
 quotes in order to avoid their special meanings in the shell. See also the
@@ -99,13 +85,11 @@ section 'SPECIFYING DESCRIPTIONS' for more information.
 The <mods> consist of zero or more changes to apply to the selected tasks, such
 as:
 
-.nf
   task <filter> <command> project:Home
   task <filter> <command> +weekend +garden due:tomorrow
   task <filter> <command> Description/annotation text
   task <filter> <command> /from/to/     <- replace first match
   task <filter> <command> /from/to/g    <- replace all matches
-.fi
 
 .SH SUBCOMMANDS
 
@@ -204,7 +188,6 @@ wish to save it, or pipe it to another command or script to convert it to
 another format. You'll find these example scripts online at
 <https://taskwarrior.org/tools/>:
 
-.nf
   export-csv.pl
   export-sql.py
   export-xml.py
@@ -215,7 +198,6 @@ another format. You'll find these example scripts online at
   export-ical.pl
   export-xml.pl
   export-yad.pl
-.fi
 
 .TP
 .B task <filter> ghistory.annual
@@ -261,16 +243,12 @@ Applies the filter then extracts only the task IDs and presents them as
 a space-separated list.  This is useful as input to a task command, to achieve
 this:
 
-.nf
   task $(task project:Home ids) modify priority:H
-.fi
 
 This example first gets the IDs for the project:Home filter, then sets
 the priority to H for each of those tasks.  This can also be achieved directly:
 
-.nf
   task project:Home modify priority:H
-.fi
 
 This command is mainly of use to external scripts.
 
@@ -280,9 +258,7 @@ Applies the filter on all tasks (even deleted and completed tasks)
 then extracts only the task UUIDs and presents them as a space-separated list.
 This is useful as input to a task command, to achieve this:
 
-.nf
   task $(task project:Home status:completed uuids) modify status:pending
-.fi
 
 This example first gets the UUIDs for the project:Home and status:completed
 filters, then makes each of those tasks pending again.
@@ -409,15 +385,8 @@ if import is to be used in automated workflows.  See taskrc(5).
 For importing other file formats, the standard task release comes with a
 few example scripts, such as:
 
-.nf
   import-todo.sh.pl
   import-yaml.pl
-.fi
-
-.TP
-.B task import-v2
-Imports tasks from the Taskwarrior v2.x format. This is used when upgrading from
-version 2.x to version 3.x.
 
 .TP
 .B task log <mods>
@@ -463,20 +432,14 @@ parses and evaluates the expression given on the command line.
 
 Examples:
 
-.nf
     task calc 1 + 1
     2
-.fi
 
-.nf
     task calc now + 8d
     2015-03-26T18:06:57
-.fi
 
-.nf
     task calc eom
     2015-03-31T23:59:59
-.fi
 
 .TP
 .B task config [<name> [<value> | '']]
@@ -484,22 +447,16 @@ Add, modify and remove settings directly in the Taskwarrior configuration.
 This command either modifies the 'name' setting with a new value of 'value',
 or adds a new entry that is equivalent to 'name=value':
 
-.nf
     task config name value
-.fi
 
 This command sets a blank value.  This has the effect of suppressing any
 default value:
 
-.nf
     task config name ''
-.fi
 
 Finally, this command removes any 'name=...' entry from the .taskrc file:
 
-.nf
     task config name
-.fi
 
 .TP
 .B task context <name>
@@ -507,9 +464,7 @@ Sets the currently active context. See the CONTEXT section.
 
 Example:
 
-.nf
     task context work
-.fi
 
 .TP
 .B task context delete <name>
@@ -518,9 +473,7 @@ set as active, it will be unset.
 
 Example:
 
-.nf
     task context delete work
-.fi
 
 .TP
 .B task context define <name> <filter>
@@ -529,11 +482,9 @@ does not affect the currently set context, just adds a new context definition.
 
 Examples:
 
-.nf
     task context define work project:Work
     task context define home project:Home or +home
     task context define superurgent due:today and +urgent
-.fi
 
 .TP
 .B task context list
@@ -555,10 +506,11 @@ are important.  Running this command generates a summary of similar information
 that should accompany a bug report.
 
 It includes compiler, library and software information.  It does not include
-any personal information, other than the location of your task data.
+any personal information, other than the location and size of your task data
+files.
 
-This command also performs a diagnostic scan of your data looking for common
-problems, such as duplicate UUIDs.
+This command also performs a diagnostic scan of your data files looking for
+common problems, such as duplicate UUIDs.
 
 .TP
 .B task execute <external command>
@@ -595,21 +547,21 @@ Shows statistics of the tasks defined by the filter. Is affected by the context.
 Shows a report of aggregated task status by project. Is affected by the context.
 
 .TP
-.B task sync
+.B task sync [init]
 The sync command synchronizes data with the Taskserver, if configured.
 
+The init subcommand should only ever be run once, and only on one client, because
+it sends all data to the Taskserver. This allows all the subsequent sync commands
+to only send small deltas.
+
 Note: If you use multiple sync clients, make sure this setting (which is the default)
 is on your primary client:
 
-.nf
   recurrence=on
-.fi
 
 and on all other clients (this is not the default):
 
-.nf
   recurrence=off
-.fi
 
 This is a workaround to avoid a recurrence bug that duplicates recurring tasks.
 
@@ -669,9 +621,7 @@ by third-party applications.
 Reports a unique set of attribute values. For example, to see all the active
 projects:
 
-.nf
   task +PENDING _unique project
-.fi
 
 .TP
 .B task <filter> _uuids
@@ -718,7 +668,6 @@ Shows the UUIDs and descriptions of matching tasks.
 Accesses and displays the DOM reference(s).  Used to extract individual values
 from tasks, or the system.  Supported DOM references are:
 
-.nf
   rc.<name>
   tw.syncneeded
   tw.program
@@ -734,7 +683,6 @@ from tasks, or the system.  Supported DOM references are:
   system.os
   <id>.<attribute>
   <uuid>.<attribute>
-.fi
 
 Note that the 'rc.<name>' reference may need to be escaped using '--' to prevent
 the reference from being interpreted as an override.
@@ -745,10 +693,8 @@ missing value, the command exits with 1.
 Additionally, some components of the attributes of particular types may be
 extracted by DOM references.
 
-.nf
   $ task _get 2.due.year
   2015
-.fi
 
 For a full list of supported attribute-specific DOM references, consult
 the online documentation at:
@@ -758,16 +704,14 @@ the online documentation at:
 
 .TP
 .B ID
-Tasks can be specified uniquely by IDs, which are the indexes of the "working
-set" of tasks (mostly pending and recurrent tasks).  The ID of a task may
-therefore change, but only when a report that displays IDs is run.  When
-modifying tasks, it is safe to rely on the last displayed ID.  Always run a
-report to check you have the right ID for a task. IDs can be given to task as a
-sequence, for example:
-
-.nf
+Tasks can be specified uniquely by IDs, which are simply the indexes of the
+tasks in the data file.  The ID of a task may therefore change, but only when
+a command is run that displays IDs.  When modifying tasks, it is safe to
+rely on the last displayed ID.  Always run a report to check you have the right
+ID for a task. IDs can be given to task as a sequence, for example,
+.br
+.B
 task 1,4-10,19 delete
-.fi
 
 .TP
 .B +tag|-tag
@@ -778,18 +722,15 @@ Certain tags (called 'special tags'), can be used to affect the way tasks are
 treated.  For example, if a task has the special tag 'nocolor', then it is
 exempt from all color rules.  The supported special tags are:
 
-.nf
     +nocolor     Disable color rules processing for this task
     +nonag       Completion of this task suppresses all nag messages
     +nocal       This task will not appear on the calendar
     +next        Elevates task so it appears on 'next' report
-.fi
 
 There are also virtual tags, which represent task metadata in tag form.  These
 tags do not exist, but can be used to filter tasks.  The supported virtual tags
 are:
 
-.nf
     ACTIVE       Matches if the task is started
     ANNOTATED    Matches if the task has annotations
     BLOCKED      Matches if the task is blocked
@@ -797,7 +738,7 @@ are:
     CHILD        Matches if the task has a parent (deprecated in 2.6.0)
     COMPLETED    Matches if the task has completed status
     DELETED      Matches if the task has deleted status
-    DUE          Matches if the task is due within the next 7 days (See rc.due)
+    DUE          Matches if the task is due
     INSTANCE     Matches if the task is a recurrent instance
     LATEST       Matches if the task is the newest added task
     MONTH        Matches if the task is due this month
@@ -821,7 +762,6 @@ are:
     WEEK         Matches if the task is due this week
     YEAR         Matches if the task is due this year
     YESTERDAY    Matches if the task was due sometime yesterday
-.fi
 
 .\" If you update the above list, update src/commands/CmdInfo.cpp and src/commands/CmdTags.cpp as well.
 
@@ -833,10 +773,6 @@ add or remove a virtual tag.
 .B project:<project-name>
 Specifies the project to which a task is related to.
 
-.TP
-.B status:pending|deleted|completed|waiting|recurring
-Specifies the state of the task.
-
 .TP
 .B priority:H|M|L or priority:
 Specifies High, Medium, Low and no priority for a task.
@@ -883,10 +819,6 @@ by '-', the specified tasks are removed from the dependency list.
 .B entry:<entry-date>
 For report purposes, specifies the date that a task was created.
 
-.TP
-.B modified:<modified-date>
-Specifies the most recent modification date.
-
 .SH ATTRIBUTE MODIFIERS
 Attribute modifiers improve filters.  Supported modifiers are:
 
@@ -927,9 +859,9 @@ calculated attributes:
 
 For example:
 
-.nf
-    task due.before:eom priority.not:L list
-.fi
+.RS
+task due.before:eom priority.not:L list
+.RE
 
 The
 .I before
@@ -949,21 +881,15 @@ The
 modifier is the same as 'before', except it also includes the moment in
 question.  For example:
 
-.nf
     task add test due:eoy
-.fi
 
 will be found when using the inclusive filter 'by':
 
-.nf
     task due.by:eoy
-.fi
 
 but not when the non-inclusive filter 'before' is used:
 
-.nf
     task due.before:eoy
-.fi
 
 this applies equally to other named dates such as 'eom', 'eod', etc; the
 modifier compares using '<=' rather than '<' like 'before' does.
@@ -972,10 +898,8 @@ The
 .I none
 modifier requires that the attribute does not have a value.  For example:
 
-.nf
     task priority:      list
     task priority.none: list
-.fi
 
 are equivalent, and list tasks that do not have a priority.
 
@@ -997,10 +921,8 @@ The
 .I has
 modifier is used to search for a substring, such as:
 
-.nf
     task description.has:foo list
     task foo                 list
-.fi
 
 These are equivalent and will return any task that has 'foo' in the description
 or annotations.
@@ -1015,17 +937,13 @@ The
 .I startswith
 modifier matches against the left, or beginning of an attribute, such that:
 
-.nf
     task project.startswith:H list
     task project:H            list
-.fi
 
 are equivalent and will match any project starting with 'H'.  Matching all
 projects not starting with 'H' is done with:
 
-.nf
     task project.not:H         list
-.fi
 
 The
 .I endswith
@@ -1036,9 +954,7 @@ The
 modifier requires that the attribute contain the whole word specified, such
 that this:
 
-.nf
     task description.word:bar list
-.fi
 
 Will match the description 'foo bar baz' but does not match 'dog food'.
 
@@ -1052,19 +968,15 @@ modifier.
 
 You can use the following operators in filter expressions:
 
-.nf
   and  or  xor  !               Logical operators
   <  <=  =  ==  !=  !==  >=  >  Relational operators
   (  )                          Precedence
-.fi
 
 For example:
 
-.nf
   task due.before:eom priority.not:L list
   task '( due < eom or priority != L )' list
   task '! ( project:Home or project:Garden )' list
-.fi
 
 The
 .I =
@@ -1088,44 +1000,32 @@ Note that the parentheses are required when using a logical operator other than
 the 'and' operator.  The reason is that some reports contain filters that must
 be combined with the command line.  Consider this example:
 
-.nf
   task project:Home or project:Garden list
-.fi
 
 While this looks correct, it is not.  The 'list' report contains a filter of:
 
-.nf
   task show report.list.filter
 
   Config Variable    Value
   -----------------  --------------
   report.list.filter status:pending
-.fi
 
 Which means the example is really:
 
-.nf
   task status:pending project:Home or project:Garden list
-.fi
 
 The implied 'and' operator makes it:
 
-.nf
   task status:pending and project:Home or project:Garden list
-.fi
 
 This is a precedence error - the 'and' and 'or' need to be grouped using
 parentheses, like this:
 
-.nf
   task status:pending and ( project:Home or project:Garden ) list
-.fi
 
 The original example therefore must be entered as:
 
-.nf
   task '( project:Home or project:Garden )' list
-.fi
 
 This includes quotes to escape the parentheses, so that the shell doesn't
 interpret them and hide them from Taskwarrior.
@@ -1133,13 +1033,11 @@ interpret them and hide them from Taskwarrior.
 There is redundancy between operators, attribute modifiers and other syntactic
 sugar.  For example, the following are all equivalent:
 
-.nf
   task foo                      list
   task /foo/                    list
   task description.contains:foo list
   task description.has:foo      list
   task 'description ~ foo'      list
-.fi
 
 .SH SPECIFYING DATES AND FREQUENCIES
 
@@ -1153,93 +1051,102 @@ configuration variable
 .RS
 .TP
 Exact specification
-.nf
-  task ... due:7/14/2008
-.fi
+task ... due:7/14/2008
 
 .TP
 ISO-8601
-.nf
-  task ... due:2013-03-14T22:30:00Z
-.fi
+task ... due:2013-03-14T22:30:00Z
 
 .TP
 Relative wording
-.nf
-  task ... due:now
-  task ... due:today
-  task ... due:yesterday
-  task ... due:tomorrow
-.fi
+task ... due:now
+.br
+task ... due:today
+.br
+task ... due:yesterday
+.br
+task ... due:tomorrow
 
 .TP
 Day number with ordinal
-.nf
-  task ... due:23rd
-  task ... due:3wks
-  task ... due:1day
-  task ... due:9hrs
-.fi
+task ... due:23rd
+.br
+task ... due:3wks
+.br
+task ... due:1day
+.br
+task ... due:9hrs
 
 .TP
 Start of next (work) week (Monday), calendar week (Sunday or Monday), month, quarter and year
-.nf
-  task ... due:sow
-  task ... due:soww
-  task ... due:socw
-  task ... due:som
-  task ... due:soq
-  task ... due:soy
-.fi
+.br
+task ... due:sow
+.br
+task ... due:soww
+.br
+task ... due:socw
+.br
+task ... due:som
+.br
+task ... due:soq
+.br
+task ... due:soy
 
 .TP
 End of current (work) week (Friday), calendar week (Saturday or Sunday), month, quarter and year
-.nf
-  task ... due:eow
-  task ... due:eoww
-  task ... due:eocw
-  task ... due:eom
-  task ... due:eoq
-  task ... due:eoy
-.fi
+.br
+task ... due:eow
+.br
+task ... due:eoww
+.br
+task ... due:eocw
+.br
+task ... due:eom
+.br
+task ... due:eoq
+.br
+task ... due:eoy
 
 .TP
 At some point or later
-.nf
-  task ... wait:later
-  task ... wait:someday
-.fi
+.br
+task ... wait:later
+.br
+task ... wait:someday
 
 This sets the wait date to 12/30/9999.
 
 .TP
 Next occurring weekday
-.nf
-  task ... due:fri
-.fi
+task ... due:fri
 
 .TP
 Predictable holidays
-.nf
-  task ... due:goodfriday
-  task ... due:easter
-  task ... due:eastermonday
-  task ... due:ascension
-  task ... due:pentecost
-  task ... due:midsommar
-  task ... due:midsommarafton
-  task ... due:juhannus
-.fi
+task ... due:goodfriday
+.br
+task ... due:easter
+.br
+task ... due:eastermonday
+.br
+task ... due:ascension
+.br
+task ... due:pentecost
+.br
+task ... due:midsommar
+.br
+task ... due:midsommarafton
+.br
+task ... due:juhannus
 .RE
 
 .SS FREQUENCIES
 Recurrence periods. Taskwarrior supports several ways of specifying the
 .I frequency
-of recurring tasks. Note that frequencies can be abbreviated.
+of recurring tasks.
 
 .RS
 .TP
-daily, day, 1day, 1days, 2day, 2days, 1da, 2da, ...
+daily, day, 1da, 2da, ...
 Every day or a number of days.
 
 .TP
@@ -1280,8 +1187,7 @@ Context is a user-defined query, which is automatically applied to all commands
 that filter the task list and to commands that create new tasks (add, log). For
 example, any report command will have its result affected by the current
 active context.  Here is a list of the commands that are affected:
-
-.nf
+.IP
     add
     burndown
     count
@@ -1300,44 +1206,33 @@ active context.  Here is a list of the commands that are affected:
     stop
     summary
     tags
-.fi
 
 All other commands are NOT affected by the context.
 
-.nf
     $ task list
     ID Age Project  Description        Urg
     1  2d  Sport    Run 5 miles        1.42
     2  1d  Home     Clean the dishes   1.14
-.fi
 
-.nf
     $ task context home
     Context 'home' set. Use 'task context none' to remove.
-.fi
 
-.nf
     $ task list
     ID Age Project  Description        Urg
     2  1d  Home     Clean the dishes   1.14
     Context 'home' set. Use 'task context none' to remove.
-.fi
 
 Task list got automatically filtered for project:Home.
 
-.nf
     $ task add Vaccuum the carpet
     Created task 3.
     Context 'home' set. Use 'task context none' to remove.
-.fi
 
-.nf
     $ task list
     ID Age Project  Description         Urg
     2  1d  Home     Clean the dishes    1.14
     3  5s  Home     Vaccuum the carpet  1.14
     Context 'home' set. Use 'task context none' to remove.
-.fi
 
 Note that the newly added task "Vaccuum the carpet" has "project:Home" set
 automatically.
@@ -1348,28 +1243,22 @@ new context's name to the 'context' command.
 
 To unset any context, use the 'none' subcommand.
 
-.nf
     $ task context none
     Context unset.
-.fi
 
-.nf
     $ task list
     ID Age Project  Description         Urg
     1  2d  Sport    Run 5 miles         1.42
     2  1d  Home     Clean the dishes    1.14
     3  7s  Home     Vaccuum the carpet  1.14
-.fi
 
 Context can be defined using the 'define' subcommand, specifying both the name
 of the new context, and it's assigned filter.
 
-.nf
     $ task context define home project:Home
     Are you sure you want to add 'context.home.read' with a value of 'project:Home'? (yes/no) yes
     Are you sure you want to add 'context.home.write' with a value of 'project:Home'? (yes/no) yes
     Context 'home' successfully defined.
-.fi
 
 Note that you were separately prompted to set the 'read' and 'write' context.
 This allows you to specify contexts that only work for reporting commands or
@@ -1377,16 +1266,13 @@ only for commands that create tasks.
 
 To remove the definition, use the 'delete' subcommand.
 
-.nf
     $ task context delete home
     Are you sure you want to remove 'context.home.read'? (yes/no) yes
     Are you sure you want to remove 'context.home.write'? (yes/no) yes
     Context 'home' deleted.
-.fi
 
 To check what is the currently active context, use the 'show' subcommand.
 
-.nf
     $ task context show
     Context 'home' with
 
@@ -1394,16 +1280,13 @@ To check what is the currently active context, use the 'show' subcommand.
     * write filter: '+home'
 
     is currently applied.
-.fi
 
 Contexts can store arbitrarily complex filters.
 
-.nf
     $ task context define family project:Family or +paul or +nancy
     Are you sure you want to add 'context.family.read' with a value of 'project:Family or +paul or +nancy'? (yes/no) yes
     Are you sure you want to add 'context.family.write' with a value of 'project:Family or +paul or +nancy'? (yes/no) no
     Context 'family' successfully defined.
-.fi
 
 Contexts are permanent, and the currently set context name is stored in the
 "context" configuration variable. The context definition is stored in the
@@ -1416,17 +1299,13 @@ filter as writeable context. The reason for this decision is that the complex
 filter in the example does not directly translate to a modification. In fact,
 if such a context is used as a writeable context, the following happens:
 
-.nf
     $ task add Call Paul
     Created task 4.
     Context 'family' set. Use 'task context none' to remove.
-.fi
 
-.nf
     $ task 4 list
     ID Age  Project Tags       Description      Urg
      4 9min Family  nancy paul or or Call Paul    0
-.fi
 
 
 There is no clear mapping between the complex filter used and the modifications
@@ -1435,20 +1314,16 @@ operators being present in the description. Taskwarrior does not try to guess
 the user intention here, and instead, the user is expected to set the
 "context.<name>.write" variable to make their intention explicit, for example:
 
-.nf
     $ task config context.family.write project:Family
     Are you sure you want to change the value of 'context.family.write' from 'project:Family or +paul or +nancy' to 'project:Family'? (yes/no) yes
     Config file /home/tbabej/.config/task/taskrc modified.
-.fi
 
-.nf
     $ task context
     Name   Type  Definition                        Active
     family read  project:Family or +paul or +nancy yes
            write project:Family                    yes
     home   read  +home                             no
            write +home                             no
-.fi
 
 Note how read and write contexts differ for context "family", while for context
 "home" they stay the same.
@@ -1457,77 +1332,77 @@ In addition, every configuration parameter can be overridden for the current
 context, by specifying context.<name>.rc.<parameter>. For example, if the default
 command for the family context should be displaying the family_report:
 
-.nf
     $ task config context.family.rc.default.command family_report
-.fi
 
 .SH COMMAND ABBREVIATION
 All Taskwarrior commands may be abbreviated as long as a unique prefix is used,
 for example:
 
-.nf
-  $ task li
-.fi
+.RS
+$ task li
+.RE
 
 is an unambiguous abbreviation for
 
-.nf
-  $ task list
-.fi
+.RS
+$ task list
+.RE
 
 but
 
-.nf
-  $ task l
-.fi
+.RS
+$ task l
+.RE
 
 could be list, ls or long.
 
 Note that you can restrict the minimum abbreviation size using the configuration
 setting:
 
-.nf
-  abbreviation.minimum=3
-.fi
+.RS
+abbreviation.minimum=3
+.RE
 
 .SH SPECIFYING DESCRIPTIONS
 Some task descriptions need to be escaped because of the shell and the special
 meaning of some characters to the shell. This can be done either by adding
 quotes to the description or escaping the special character:
 
-.nf
-  $ task add "quoted ' quote"
-  $ task add escaped \\' quote
-.fi
+.RS
+$ task add "quoted ' quote"
+.br
+$ task add escaped \\' quote
+.RE
 
 The argument \-\- (a double dash) tells Taskwarrior to treat all other args
 as description:
 
-.nf
-  $ task add -- project:Home needs scheduling
-.fi
+.RS
+$ task add -- project:Home needs scheduling
+.RE
 
 In other situations, the shell sees spaces and breaks up arguments.  For
 example, this command:
 
-.nf
-  $ task 123 modify /from this/to that/
-.fi
+.RS
+$ task 123 modify /from this/to that/
+.RE
 
 is broken up into several arguments, which is corrected with quotes:
 
-.nf
-  $ task 123 modify "/from this/to that/"
-.fi
+.RS
+$ task 123 modify "/from this/to that/"
+.RE
 
 It is sometimes necessary to force the shell to pass quotes to Taskwarrior
 intact, so you can use:
 
-.nf
-  $ task add project:\\'Three Word Project\\' description
-.fi
+.RS
+$ task add project:\\'Three Word Project\\' description
+.RE
 
-Taskwarrior supports Unicode using only the UTF8 encoding.
+Taskwarrior supports Unicode using only the UTF8 encoding, with no Byte Order
+Marks in the data files.
 
 .SH CONFIGURATION FILE AND OVERRIDE OPTIONS
 Taskwarrior stores its configuration in a file in the user's home directory:
@@ -1578,13 +1453,21 @@ will check if $XDG_CONFIG_HOME/task/taskrc exists and attempt to read it
 
 .TP
 ~/.task
-The default directory where task stores its data. The location can be
-configured in the configuration variable 'data.location', or overridden with
-the TASKDATA environment variable.
+The default directory where task stores its data files. The location
+can be configured in the configuration variable 'data.location', or
+overridden with the TASKDATA environment variable..
 
 .TP
-~/.task/taskchampion.sqlite3
-The database file.
+~/.task/pending.data
+The file that contains the tasks that are not yet done.
+
+.TP
+~/.task/completed.data
+The file that contains the completed ("done") tasks.
+
+.TP
+~/.task/undo.data
+The file that contains information needed by the "undo" command.
 
 .SH "CREDITS & COPYRIGHTS"
 Copyright (C) 2006 \- 2021 T. Babej, P. Beckingham, F. Hernandez.

doc/man/taskrc.5.in

@@ -18,43 +18,43 @@ obtains its configuration data from a file called
 .I .taskrc
 \&. This file is normally located in the user's home directory:
 
-.nf
-    $HOME/.taskrc
-.fi
+.RS
+$HOME/.taskrc
+.RE
 
 The default location can be overridden using the
 .I rc:
 attribute when running task:
 
-.nf
-    $ task rc:<directory-path>/.taskrc ...
-.fi
+.RS
+$ task rc:<directory-path>/.taskrc ...
+.RE
 
 or using the TASKRC environment variable:
 
-.nf
-    $ TASKRC=/tmp/.taskrc task ...
-.fi
+.RS
+$ TASKRC=/tmp/.taskrc task ...
+.RE
 
 Additionally, if no ~/.taskrc exists, taskwarrior will check if the XDG_CONFIG_HOME environment variable is defined:
 
-.nf
-    $ XDG_CONFIG_HOME=~/.config task ...
-.fi
+.RS
+$ XDG_CONFIG_HOME=~/.config task ...
+.RE
 
 Individual options can be overridden by using the
 .I rc.<name>:
 attribute when running task:
 
-.nf
-    $ task rc.<name>:<value> ...
-.fi
+.RS
+$ task rc.<name>:<value> ...
+.RE
 
 or
 
-.nf
-    $ task rc.<name>=<value> ...
-.fi
+.RS
+$ task rc.<name>=<value> ...
+.RE
 
 If
 .B Taskwarrior
@@ -65,9 +65,9 @@ file in the user's home directory.
 
 The .taskrc file follows a very simple syntax defining name/value pairs:
 
-.nf
-    <name> = <value>
-.fi
+.RS
+<name> = <value>
+.RE
 
 There may be whitespace around <name>, '=' and <value>, and it is ignored.
 Whitespace within the <value> is left intact.
@@ -77,11 +77,11 @@ Values support UTF8 as well as JSON encoding, such as \\uNNNN.
 
 Note that Taskwarrior is flexible about the values used to represent Boolean
 items. You can use "1" to enable, anything else is interpreted as disabled.
-The values "on", "yes", "y" and "true" are also supported.
+The values "on", "yes", "y" and "true" are currently supported but deprecated.
 
-.nf
-    include <file>
-.fi
+.RS
+include <file>
+.RE
 
 There may be whitespace around 'include' and <file>. The file may be an
 absolute or relative path, and the special character '~' is expanded to mean
@@ -95,9 +95,9 @@ respect to the following directories (listed in order of precedence):
 Note that environment variables are also expanded in paths (and any other
 taskrc variables).
 
-.nf
-    # <comment>
-.fi
+.RS
+# <comment>
+.RE
 
 A comment consists of the character '#', and extends from the '#' to the end
 of the line. There is no way to comment a multi-line block. There may be
@@ -108,9 +108,9 @@ that makes use of every default. The contents of the .taskrc file therefore
 represent overrides of the default values. To remove a default value completely
 there must be an entry like this:
 
-.nf
-    <name> =
-.fi
+.RS
+<name> =
+.RE
 
 This entry overrides the default value with a blank value.
 
@@ -118,28 +118,28 @@ This entry overrides the default value with a blank value.
 You can edit your .taskrc file by hand if you wish, or you can use the 'config'
 command. To permanently set a value in your .taskrc file, use this command:
 
-.nf
-    $ task config nag "You have more urgent tasks."
-.fi
+.RS
+$ task config nag "You have more urgent tasks."
+.RE
 
 To delete an entry, use this command:
 
-.nf
-    $ task config nag
-.fi
+.RS
+$ task config nag
+.RE
 
 Taskwarrior will then use the default value. To explicitly set a value to
 blank, and therefore avoid using the default value, use this command:
 
-.nf
-    $ task config nag ""
-.fi
+.RS
+$ task config nag ""
+.RE
 
 Taskwarrior will also display all your settings with this command:
 
-.nf
-    $ task show
-.fi
+.RS
+$ task show
+.RE
 
 and in addition, will also perform a check of all the values in the file,
 warning you of anything it finds amiss.
@@ -149,19 +149,20 @@ The .taskrc can include other files containing configuration settings by using t
 .B include
 statement:
 
-.nf
-    include <path/to/the/configuration/file/to/be/included>
-.fi
+.RS
+include <path/to/the/configuration/file/to/be/included>
+.RE
 
 By using include files you can divide your main configuration file into several
 ones containing just the relevant configuration data like colors, etc.
 
 There are two excellent uses of includes in your .taskrc, shown here:
 
-.nf
-    include holidays.en-US.rc
-    include dark-16.theme
-.fi
+.RS
+include holidays.en-US.rc
+.br
+include dark-16.theme
+.RE
 
 This includes two standard files that are distributed with Taskwarrior, which
 define a set of US holidays, and set up a 16-color theme to use, to color the
@@ -172,7 +173,7 @@ These environment variables override defaults, but not command-line arguments.
 
 .TP
 .B TASKDATA=~/.task
-This overrides the default path for the Taskwarrior data.
+This overrides the default path for the Taskwarrior data files.
 
 .TP
 .B TASKRC=~/.taskrc
@@ -196,7 +197,7 @@ Valid variable names and their default values are:
 
 .TP
 .B data.location=$HOME/.task
-This is a path to the directory containing all the Taskwarrior data. By
+This is a path to the directory containing all the Taskwarrior files. By
 default, it is set up to be ~/.task, for example: /home/paul/.task
 
 Note that you can use the
@@ -210,17 +211,19 @@ Note that the TASKDATA environment variable overrides this setting.
 This is a path to the hook scripts directory. By default it is ~/.task/hooks.
 
 .TP
-.B gc=1
-Can be used to temporarily suspend rebuilding, so that task IDs don't change.
-Note that this should be used in the form of a command line override (task
-rc.gc=0 ...), and not permanently used in the .taskrc file, as this
-significantly affects performance in the long term.
+.B locking=1
+Determines whether to use file locking when accessing the pending.data and
+completed.data files. Defaults to "1". Solaris users who store the data
+files on an NFS mount may need to set locking to "0". Note that there is
+danger in setting this value to "0" - another program (or another instance of
+task) may write to the task.pending file at the same time.
 
 .TP
-.B purge.on-sync=0
-If set, old tasks will be purged automatically after each synchronization.
-Tasks are identified as "old" when they have status "Deleted" and have not
-been modified for 180 days.
+.B gc=1
+Can be used to temporarily suspend garbage collection (gc), so that task IDs
+don't change. Note that this should be used in the form of a command line
+override (task rc.gc=0 ...), and not permanently used in the .taskrc file,
+as this significantly affects performance in the long term.
 
 .TP
 .B hooks=1
@@ -238,13 +241,6 @@ rc.data.location or TASKDATA override) is missing. Default value is '0'.
 Determines whether to use ioctl to establish the size of the window you are
 using, for text wrapping.
 
-.TP
-.B limit:25
-Specifies the desired number of tasks a report should show, if a positive
-integer is given.  The value 'page' may also be used, and will limit the
-report output to as many lines of text as will fit on screen. Default value
-is '25'.
-
 .TP
 .B defaultwidth=80
 The width of output used when auto-detection support is not available. Defaults
@@ -296,14 +292,12 @@ is most readily parsed and used by shell scripts.
 Alternatively, you can specify a comma-separated list of verbosity tokens that
 control specific occasions when output is generated. This list may contain:
 
-.nf
     blank      Inserts extra blank lines in output, for clarity
     header     Messages that appear before report output (this includes .taskrc/.task overrides and the "[task next]" message)
     footnote   Messages that appear after report output (mostly status messages and change descriptions)
     label      Column labels on tabular reports
     new-id     Provides feedback on any new task with IDs (and UUIDs for new tasks with ID 0, such as new completed tasks).
     new-uuid   Provides feedback on any new task with UUIDs. Overrides new-id. Useful for automation.
-    news       Reminds to read new release highlights until the user runs "task news".
     affected   Reports 'N tasks affected' and similar
     edit       Used the verbose template for the 'edit' command
     special    Feedback when applying special tags
@@ -314,7 +308,6 @@ control specific occasions when output is generated. This list may contain:
     override   Notification when configuration options are overridden
     recur      Notification when a new recurring task instance is created
     default    Notifications about taskwarrior choosing to perform a default action.
-.fi
 
 The tokens "affected", "new-id", "new-uuid", "project", "override" and "recur"
 imply "footnote".
@@ -326,20 +319,14 @@ and the "nothing" setting is equivalent to none of the tokens being specified.
 
 Here are the shortcut equivalents:
 
-.nf
     verbose=on
-    verbose=blank,header,footnote,label,new-id,news,affected,edit,special,project,sync,filter,override,recur
-.fi
+    verbose=blank,header,footnote,label,new-id,affected,edit,special,project,sync,filter,override,recur
 
-.nf
     verbose=0
     verbose=blank,label,new-id,edit
-.fi
 
-.nf
     verbose=nothing
     verbose=
-.fi
 
 Those additional comments are sent to the standard error for header, footnote
 and project. The others are sent to standard output.
@@ -508,6 +495,13 @@ weekly recurring task is added with a due date of tomorrow, and recurrence.limit
 is set to 2, then a report will list 2 pending recurring tasks, one for tomorrow,
 and one for a week from tomorrow.
 
+.TP
+.B undo.style=side
+When the 'undo' command is run, Taskwarrior presents a before and after
+comparison of the data. This can be in either the 'side' style, which compares
+values side-by-side in a table, or 'diff' style, which uses a format similar to
+the 'diff' command.
+
 .TP
 .B abbreviation.minimum=2
 Minimum length of any abbreviated command/value. This means that "ve", "ver",
@@ -522,7 +516,7 @@ debug output can be useful. It can also help explain how the command line is
 being parsed, but the information is displayed in a developer-friendly, not a
 user-friendly way.
 
-Turning debug on automatically sets debug.hooks=1 and  debug.parser=1
+Turning debug on automatically sets debug.hooks=1, debug.parser=1 and debug.tls=2
 if they do not already have assigned values. Defaults to "0".
 
 .TP
@@ -537,6 +531,11 @@ Level 1 shows the final parse tree.
 Level 2 shows the parse tree from all phases of the parse.
 Level 3 shows expression evaluation details.
 
+.TP
+.B debug.tls=0
+Controls the GnuTLS diagnostic level. For 'sync' debugging. Level 0 means no
+diagnostics. Level 9 is the highest. Level 2 is a good setting for debugging.
+
 .TP
 .B obfuscate=0
 When set to '1', will replace all report text with 'xxx'.
@@ -583,29 +582,51 @@ are formatted according to dateformat.
 The default value is the ISO-8601 standard: Y-M-D. The string can contain the
 characters:
 
-.nf
-    m  minimal-digit month,    for example 1 or 12
-    d  minimal-digit day,      for example 1 or 30
-    y  two-digit year,         for example 09 or 12
-    D  two-digit day,          for example 01 or 30
-    M  two-digit month,        for example 01 or 12
-    Y  four-digit year,        for example 2009 or 2015
-    a  short name of weekday,  for example Mon or Wed
-    A  long name of weekday,   for example Monday or Wednesday
-    b  short name of month,    for example Jan or Aug
-    B  long name of month,     for example January or August
-    v  minimal-digit week,     for example 3 or 37
-    V  two-digit week,         for example 03 or 37
-    h  minimal-digit hour,     for example 3 or 21
-    n  minimal-digit minutes,  for example 5 or 42
-    s  minimal-digit seconds,  for example 7 or 47
-    H  two-digit hour,         for example 03 or 21
-    N  two-digit minutes,      for example 05 or 42
-    S  two-digit seconds,      for example 07 or 47
-    J  three-digit Julian day, for example 023 or 365
-    j  Julian day,             for example 23 or 365
-    w  Week day,               for example 0 for Monday, 5 for Friday
-.fi
+.RS
+.RS
+m  minimal-digit month,    for example 1 or 12
+.br
+d  minimal-digit day,      for example 1 or 30
+.br
+y  two-digit year,         for example 09 or 12
+.br
+D  two-digit day,          for example 01 or 30
+.br
+M  two-digit month,        for example 01 or 12
+.br
+Y  four-digit year,        for example 2009 or 2015
+.br
+a  short name of weekday,  for example Mon or Wed
+.br
+A  long name of weekday,   for example Monday or Wednesday
+.br
+b  short name of month,    for example Jan or Aug
+.br
+B  long name of month,     for example January or August
+.br
+v  minimal-digit week,     for example 3 or 37
+.br
+V  two-digit week,         for example 03 or 37
+.br
+h  minimal-digit hour,     for example 3 or 21
+.br
+n  minimal-digit minutes,  for example 5 or 42
+.br
+s  minimal-digit seconds,  for example 7 or 47
+.br
+H  two-digit hour,         for example 03 or 21
+.br
+N  two-digit minutes,      for example 05 or 42
+.br
+S  two-digit seconds,      for example 07 or 47
+.br
+J  three-digit Julian day, for example 023 or 365
+.br
+j  Julian day,             for example 23 or 365
+.br
+w  Week day,               for example 0 for Monday, 5 for Friday
+.RE
+.RE
 
 .RS
 The characters 'v', 'V', 'a' and 'A' can only be used for formatting printed
@@ -617,24 +638,37 @@ The string may also contain other characters to act as spacers, or formatting.
 Examples for other values of dateformat:
 .RE
 
-.nf
-    d/m/Y  would use for input and output 24/7/2009
-    yMD    would use for input and output 090724
-    M-D-Y  would use for input and output 07-24-2009
-.fi
+.RS
+.RS
+.br
+d/m/Y  would use for input and output 24/7/2009
+.br
+yMD    would use for input and output 090724
+.br
+M-D-Y  would use for input and output 07-24-2009
+.RE
+.RE
 
 .RS
 Examples for other values of dateformat.report:
 .RE
 
-.nf
-    a D b Y (V)   would emit "Fri 24 Jul 2009 (30)"
-    A, B D, Y     would emit "Friday, July 24, 2009"
-    wV a Y-M-D    would emit "w30 Fri 2009-07-24"
-    yMD.HN        would emit "110124.2342"
-    m/d/Y H:N     would emit "1/24/2011 10:42"
-    a D b Y H:N:S would emit "Mon 24 Jan 2011 11:19:42"
-.fi
+.RS
+.RS
+.br
+a D b Y (V)   would emit "Fri 24 Jul 2009 (30)"
+.br
+A, B D, Y     would emit "Friday, July 24, 2009"
+.br
+wV a Y-M-D    would emit "w30 Fri 2009-07-24"
+.br
+yMD.HN        would emit "110124.2342"
+.br
+m/d/Y H:N     would emit "1/24/2011 10:42"
+.br
+a D b Y H:N:S would emit "Mon 24 Jan 2011 11:19:42"
+.RE
+.RE
 
 .RS
 Undefined fields are put to their minimal valid values (1 for month and day and
@@ -643,10 +677,14 @@ field that is set. Otherwise, they are set to the corresponding values of
 "now". For example:
 .RE
 
-.nf
-    8/1/2013  with m/d/Y   implies August 1, 2013 at midnight (inferred)
-    8/1 20:40 with m/d H:N implies August 1, 2013 (inferred) at 20:40
-.fi
+.RS
+.RS
+.br
+8/1/2013  with m/d/Y   implies August 1, 2013 at midnight (inferred)
+.br
+8/1 20:40 with m/d H:N implies August 1, 2013 (inferred) at 20:40
+.RE
+.RE
 
 .TP
 .B date.iso=1
@@ -740,19 +778,28 @@ Holidays are entered either directly in the .taskrc file or via an include file
 that is specified in .taskrc. For single-day holidays the name and the date is
 required to be given:
 
-.nf
-    holiday.towel.name=Day of the towel
-    holiday.towel.date=20100525
-.fi
+.RS
+.RS
+.br
+holiday.towel.name=Day of the towel
+.br
+holiday.towel.date=20100525
+.RE
+.RE
 
 For holidays that span a range of days (i.e. vacation), you can use a start date
 and an end date:
 
-.nf
-    holiday.sysadmin.name=System Administrator Appreciation Week
-    holiday.sysadmin.start=20100730
-    holiday.sysadmin.end=20100805
-.fi
+.RS
+.RS
+.br
+holiday.sysadmin.name=System Administrator Appreciation Week
+.br
+holiday.sysadmin.start=20100730
+.br
+holiday.sysadmin.end=20100805
+.RE
+.RE
 
 .RS
 Dates are to be entered according to the setting in the dateformat.holiday
@@ -765,17 +812,24 @@ Easter (easter), Easter Monday (eastermonday), Ascension (ascension), Pentecost
 (pentecost). The date for these holidays is the given keyword:
 .RE
 
-.nf
-    holiday.eastersunday.name=Easter
-    holiday.eastersunday.date=easter
-.fi
+.RS
+.RS
+.br
+holiday.eastersunday.name=Easter
+.br
+holiday.eastersunday.date=easter
+.RE
+.RE
 
 Note that the Taskwarrior distribution contains example holiday files that can
 be included like this:
 
-.nf
-    include holidays.en-US.rc
-.fi
+.RS
+.RS
+.br
+include holidays.en-US.rc
+.RE
+.RE
 
 .SS DEPENDENCIES
 
@@ -863,9 +917,10 @@ Task is deleted.
 .RS
 To disable a coloration rule for which there is a default, set the value to
 nothing, for example:
-.nf
-    color.tagged=
-.fi
+.RS
+.B color.tagged=
+.RE
+.RE
 
 .RS
 By default, colors produced by rules blend. This has the advantage of
@@ -1042,9 +1097,6 @@ yellow bars.
 .RS
 Colors used by the undo command, to indicate the values both before and after
 a change that is to be reverted.
-
-Currently not supported.
-
 .RE
 
 .TP
@@ -1203,23 +1255,30 @@ default.command=next
 Provides a default command that is run every time Taskwarrior is invoked with no
 arguments. For example, if set to:
 
-.nf
-    default.command=project:foo list
-.fi
+.RS
+.RS
+default.command=project:foo list
+.RE
+.RE
 
 .RS
 then Taskwarrior will run the "project:foo list" command if no command is
 specified. This means that by merely typing
 .RE
 
-.nf
-    $ task
-    [task project:foo list]
-
-    ID Project Pri Description
-     1 foo     H   Design foo
-     2 foo         Build foo
-.fi
+.RS
+.RS
+$ task
+.br
+[task project:foo list]
+.br
+\&
+.br
+ID Project Pri Description
+ 1 foo     H   Design foo
+ 2 foo         Build foo
+.RE
+.RE
 
 .SS REPORTS
 
@@ -1258,16 +1317,12 @@ specified by using the column ids post-fixed by a "+" for ascending sort order
 or a "-" for descending sort order. The sort IDs are separated by commas.
 For example:
 
-.nf
     report.list.sort=due+,priority-,start.active-,project+
-.fi
 
 Additionally, after the "+" or "-", there can be a solidus "/" which indicates
 that there are breaks after the column values change. For example:
 
-.nf
     report.minimal.sort=project+/,description+
-.fi
 
 This sort order now specifies that there is a listing break between each
 project. A listing break is simply a blank line, which provides a visual
@@ -1472,6 +1527,58 @@ context.home.rc.default.command=home_report
 These configuration settings are used to connect and sync tasks with the task
 server.
 
+.TP
+.B taskd.server=<host>:<port>
+.RS
+Specifies the hostname and port of the Taskserver. Hostname may be an IPv4 or
+IPv6 address, or domain. Port is an integer.
+.RE
+
+.TP
+.B taskd.credentials=<organization>/<user>/<key>
+.RS
+User identification for the Taskserver, which includes a private key.
+.RE
+
+.TP
+.B taskd.certificate=<path>
+.RS
+Specifies the path to the client certificate used for identification with the
+Taskserver.
+.RE
+
+.TP
+.B taskd.key=<path>
+.RS
+Specifies the path to the client key used for encrypted communication with the
+Taskserver.
+.RE
+
+.TP
+.B taskd.ca=<path>
+.RS
+Specifies the path to the CA certificate in the event that your Taskserver is
+using a self-signed certificate. Optional.
+.RE
+
+.TP
+.B taskd.trust=strict|ignore hostname|allow all
+.RS
+This settings allows you to override the trust level when server certificates
+are validated. With "allow all", the server certificate is trusted
+automatically. With "ignore hostname", the server certificate is verified but
+the hostname is ignored. With "strict", the server certificate is verified.
+Default is "strict", which requires full validation.
+.RE
+
+.TP
+.B taskd.ciphers=NORMAL
+Override of the cipher selection. The set of ciphers used by TLS may be
+controlled by both server and client. There must be some overlap between
+client and server supported ciphers, or communication cannot occur.
+Default is "NORMAL". See GnuTLS documentation for full details.
+.RE
+
 .SH "CREDITS & COPYRIGHTS"
 Copyright (C) 2006 \- 2021 T. Babej, P. Beckingham, F. Hernandez.
 

doc/misc/themes/README

@@ -25,3 +25,4 @@ Using a solarized light terminal, run the following:
 
 Note that for the solarized themes, the terminal color palette needs to be set
 to specific colors.
+

doc/misc/themes/setup

@@ -30,3 +30,4 @@ task rc:x add Deleted_1
 
 task rc:x 14 mod depends:13
 task rc:x 15 delete
+

doc/rc/bubblegum-256.theme

@@ -1,99 +0,0 @@
-###############################################################################
-#
-# Copyright 2006 - 2021, Tomas Babej, Paul Beckingham, Federico Hernandez.
-#
-# Permission is hereby granted, free of charge, to any person obtaining a copy
-# of this software and associated documentation files (the "Software"), to deal
-# in the Software without restriction, including without limitation the rights
-# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-# copies of the Software, and to permit persons to whom the Software is
-# furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice shall be included
-# in all copies or substantial portions of the Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
-# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
-# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-# SOFTWARE.
-#
-# https://www.opensource.org/licenses/mit-license.php
-#
-###############################################################################
-
-# Theme author: Adrian Galilea @adriangalilea
-
-rule.precedence.color=deleted,completed,active,keyword.,tag.,project.,overdue,scheduled,due.today,due,blocked,blocking,recurring,tagged,uda.
-
-# General decoration
-color.label=
-color.label.sort=
-color.alternate=on gray2
-color.header=rgb013
-color.footnote=rgb013
-color.warning=rgb520
-color.error=red
-color.debug=blue
-
-# Task state
-color.completed=
-color.deleted=
-color.active=rgb553
-color.recurring=bright rgb535
-color.scheduled=
-color.until=
-color.blocked=gray10
-color.blocking=on rgb002
-
-# Project
-color.project.none=
-
-# Priority
-color.uda.priority.H=rgb435
-color.uda.priority.L=gray15
-
-# Tags
-color.tag.next=rgb253
-color.tag.none=
-color.tagged=
-
-# Due
-color.due=
-color.due.today=rgb125
-color.overdue=bold inverse
-
-# Report: burndown
-color.burndown.pending=on rgb103
-color.burndown.started=on rgb214
-color.burndown.done=on gray4
-
-# Report: history
-color.history.add=color0 on rgb105
-color.history.done=color0 on rgb205
-color.history.delete=color0 on rgb305
-
-# Report: summary
-color.summary.bar=white on rgb104
-color.summary.background=white on rgb001
-
-# Command: calendar
-color.calendar.due=color0 on rgb325
-color.calendar.due.today=color0 on rgb404
-color.calendar.holiday=color15 on rgb102
-color.calendar.overdue=color0 on color5
-color.calendar.scheduled=
-color.calendar.today=color15 on rgb103
-color.calendar.weekend=gray12 on gray3
-color.calendar.weeknumber=rgb104
-
-# Command: sync
-color.sync.added=gray4
-color.sync.changed=rgb214
-color.sync.rejected=rgb103
-
-# Command: undo
-color.undo.before=rgb103
-color.undo.after=rgb305

doc/rc/dark-16.theme

@@ -86,7 +86,6 @@ color.calendar.due=white on red
 color.calendar.due.today=bold white on red
 color.calendar.holiday=black on bright yellow
 color.calendar.overdue=black on bright red
-color.calendar.scheduled=
 color.calendar.today=bold white on bright blue
 color.calendar.weekend=white on bright black
 color.calendar.weeknumber=bold blue
@@ -99,3 +98,4 @@ color.sync.rejected=red
 # Command: undo
 color.undo.after=green
 color.undo.before=red
+

doc/rc/dark-256.theme

@@ -82,7 +82,6 @@ color.summary.bar=black on rgb141
 color.calendar.due.today=color15 on color1
 color.calendar.due=color0 on color1
 color.calendar.holiday=color0 on color11
-color.calendar.scheduled=
 color.calendar.overdue=color0 on color9
 color.calendar.today=color15 on rgb013
 color.calendar.weekend=on color235
@@ -96,3 +95,4 @@ color.sync.rejected=color9
 # Command: undo
 color.undo.after=color2
 color.undo.before=color1
+

doc/rc/dark-blue-256.theme

@@ -83,7 +83,6 @@ color.calendar.due.today=color0 on color252
 color.calendar.due=color0 on color249
 color.calendar.holiday=color255 on rgb013
 color.calendar.overdue=color0 on color255
-color.calendar.scheduled=
 color.calendar.today=color0 on rgb115
 color.calendar.weekend=on color235
 color.calendar.weeknumber=rgb015
@@ -96,3 +95,4 @@ color.sync.rejected=rgb004
 # Command: undo
 color.undo.after=rgb035
 color.undo.before=rgb013
+

doc/rc/dark-gray-256.theme

@@ -83,7 +83,6 @@ color.calendar.due=on gray8
 color.calendar.due.today=black on gray15
 color.calendar.holiday=black on gray20
 color.calendar.overdue=gray2 on gray10
-color.calendar.scheduled=
 color.calendar.today=bold white
 color.calendar.weekend=on gray2
 color.calendar.weeknumber=gray6
@@ -96,3 +95,4 @@ color.sync.rejected=gray5 on gray23
 # Command: undo
 color.undo.before=white on black
 color.undo.after=black on white
+

doc/rc/dark-gray-blue-256.theme

@@ -83,7 +83,6 @@ color.calendar.due=color0 on gray10
 color.calendar.due.today=color0 on gray15
 color.calendar.holiday=color15 on rgb005
 color.calendar.overdue=color0 on gray20
-color.calendar.scheduled=
 color.calendar.today=underline black on color15
 color.calendar.weekend=on gray4
 color.calendar.weeknumber=gray10
@@ -96,3 +95,4 @@ color.sync.rejected=gray23
 # Command: undo
 color.undo.before=rgb013
 color.undo.after=rgb035
+

doc/rc/dark-green-256.theme

@@ -83,7 +83,6 @@ color.calendar.due.today=color0 on color225
 color.calendar.due=color0 on color249
 color.calendar.holiday=rgb151 on rgb020
 color.calendar.overdue=color0 on color255
-color.calendar.scheduled=
 color.calendar.today=color0 on rgb151
 color.calendar.weekend=on color235
 color.calendar.weeknumber=rgb010

doc/rc/dark-red-256.theme

@@ -83,7 +83,6 @@ color.calendar.due.today=color0 on color252
 color.calendar.due=color0 on color249
 color.calendar.holiday=rgb522 on rgb300
 color.calendar.overdue=color0 on color255
-color.calendar.scheduled=
 color.calendar.today=color0 on rgb511
 color.calendar.weekend=on color235
 color.calendar.weeknumber=rgb100
@@ -96,3 +95,4 @@ color.sync.rejected=rgb200
 # Command: undo
 color.undo.after=rgb511
 color.undo.before=rgb200
+

doc/rc/dark-violets-256.theme

@@ -83,7 +83,6 @@ color.calendar.due=color0 on rgb325
 color.calendar.due.today=color0 on rgb404
 color.calendar.holiday=color15 on rgb102
 color.calendar.overdue=color0 on color5
-color.calendar.scheduled=
 color.calendar.today=color15 on rgb103
 color.calendar.weekend=gray12 on gray3
 color.calendar.weeknumber=rgb104
@@ -96,3 +95,4 @@ color.sync.rejected=rgb103
 # Command: undo
 color.undo.before=rgb103
 color.undo.after=rgb305
+

doc/rc/dark-yellow-green.theme

@@ -83,7 +83,6 @@ color.calendar.due=color0 on rgb440
 color.calendar.due.today=color0 on rgb430
 color.calendar.holiday=rgb151 on rgb020
 color.calendar.overdue=color0 on rgb420
-color.calendar.scheduled=
 color.calendar.today=color15 on rgb110
 color.calendar.weekend=on color235
 color.calendar.weeknumber=rgb110
@@ -96,3 +95,4 @@ color.sync.rejected=rgb110
 # Command: undo
 color.undo.before=rgb021
 color.undo.after=rgb042
+

doc/rc/light-16.theme

@@ -83,7 +83,6 @@ color.calendar.due=on bright green
 color.calendar.due.today=blue on bright yellow
 color.calendar.holiday=on yellow
 color.calendar.overdue=on bright red
-color.calendar.scheduled=
 color.calendar.today=blue
 color.calendar.weekend=on white
 color.calendar.weeknumber=blue
@@ -96,3 +95,4 @@ color.sync.rejected=red
 # Command: undo
 color.undo.before=yellow
 color.undo.after=green
+

doc/rc/light-256.theme

@@ -65,7 +65,7 @@ color.due.today=on rgb353
 color.overdue=on rgb544
 
 # Report: burndown
-color.burndown.pending=on rgb411
+color.burndown.pending=on rgb411 
 color.burndown.started=on rgb550
 color.burndown.done=on rgb151
 
@@ -83,7 +83,6 @@ color.calendar.due=on rgb343
 color.calendar.due.today=on rgb353
 color.calendar.holiday=color0 on rgb530
 color.calendar.overdue=on rgb533
-color.calendar.scheduled=
 color.calendar.today=rgb005
 color.calendar.weekend=on gray21
 color.calendar.weeknumber=gray16
@@ -96,3 +95,4 @@ color.sync.rejected=red
 # Command: undo
 color.undo.before=yellow
 color.undo.after=green
+

doc/rc/no-color.theme

@@ -86,7 +86,6 @@ color.calendar.due=
 color.calendar.due.today=
 color.calendar.holiday=
 color.calendar.overdue=
-color.calendar.scheduled=
 color.calendar.today=
 color.calendar.weekend=
 color.calendar.weeknumber=
@@ -99,3 +98,4 @@ color.sync.rejected=
 # Command: undo
 color.undo.after=
 color.undo.before=
+

doc/rc/refresh

@@ -6,3 +6,4 @@ do
   echo $locale
   ../../scripts/add-ons/update-holidays.pl --locale $locale --file holidays.${locale}.rc
 done
+

doc/rc/solarized-dark-256.theme

@@ -100,7 +100,6 @@ color.calendar.due=color0 on color9
 color.calendar.due.today=color0 on color1
 color.calendar.holiday=color0 on color3
 color.calendar.overdue=color0 on color5
-color.calendar.scheduled=
 color.calendar.today=color0 on color4
 color.calendar.weekend=on color0
 color.calendar.weeknumber=color4
@@ -113,3 +112,4 @@ color.sync.rejected=color13
 # Command: undo
 color.undo.after=color2
 color.undo.before=color1
+

doc/rc/solarized-light-256.theme

@@ -100,7 +100,6 @@ color.calendar.due=color7 on color9
 color.calendar.due.today=color7 on color1
 color.calendar.holiday=color7 on color3
 color.calendar.overdue=color7 on color5
-color.calendar.scheduled=
 color.calendar.today=color7 on color4
 color.calendar.weekend=on color7
 color.calendar.weeknumber=color14
@@ -113,3 +112,4 @@ color.sync.rejected=color13
 # Command: undo
 color.undo.after=color2
 color.undo.before=color1
+

docker-compose.yml

@@ -1,17 +1,57 @@
 version: '3'
 services:
-  test-fedora40:
+  test-centos7:
     build:
         context: .
-        dockerfile: test/docker/fedora40
+        dockerfile: test/docker/centos7
     network_mode: "host"
     security_opt:
       - label=type:container_runtime_t
     tty: true
-  test-fedora41:
+  test-centos8:
     build:
         context: .
-        dockerfile: test/docker/fedora41
+        dockerfile: test/docker/centos8
+    network_mode: "host"
+    security_opt:
+      - label=type:container_runtime_t
+    tty: true
+  test-fedora32:
+    build:
+        context: .
+        dockerfile: test/docker/fedora32
+    network_mode: "host"
+    security_opt:
+      - label=type:container_runtime_t
+    tty: true
+  test-fedora33:
+    build:
+        context: .
+        dockerfile: test/docker/fedora33
+    network_mode: "host"
+    security_opt:
+      - label=type:container_runtime_t
+    tty: true
+  test-fedora34:
+    build:
+        context: .
+        dockerfile: test/docker/fedora34
+    network_mode: "host"
+    security_opt:
+      - label=type:container_runtime_t
+    tty: true
+  test-fedora35:
+    build:
+        context: .
+        dockerfile: test/docker/fedora35
+    network_mode: "host"
+    security_opt:
+      - label=type:container_runtime_t
+    tty: true
+  test-ubuntu1804:
+    build:
+        context: .
+        dockerfile: test/docker/ubuntu1804
     network_mode: "host"
     security_opt:
       - label=type:container_runtime_t
@@ -24,10 +64,26 @@ services:
     security_opt:
       - label=type:container_runtime_t
     tty: true
-  test-ubuntu2204:
+  test-ubuntu2104:
     build:
         context: .
-        dockerfile: test/docker/ubuntu2204
+        dockerfile: test/docker/ubuntu2104
+    network_mode: "host"
+    security_opt:
+      - label=type:container_runtime_t
+    tty: true
+  test-ubuntu2110:
+    build:
+        context: .
+        dockerfile: test/docker/ubuntu2110
+    network_mode: "host"
+    security_opt:
+      - label=type:container_runtime_t
+    tty: true
+  test-debianstable:
+    build:
+        context: .
+        dockerfile: test/docker/debianstable
     network_mode: "host"
     security_opt:
       - label=type:container_runtime_t
@@ -40,10 +96,18 @@ services:
     security_opt:
       - label=type:container_runtime_t
     tty: true
-  test-opensuse:
+  test-gentoo:
     build:
         context: .
-        dockerfile: test/docker/opensuse
+        dockerfile: test/docker/gentoo
+    network_mode: "host"
+    security_opt:
+      - label=type:container_runtime_t
+    tty: true
+  test-opensuse15:
+    build:
+        context: .
+        dockerfile: test/docker/opensuse15
     network_mode: "host"
     security_opt:
       - label=type:container_runtime_t

docker/task.dockerfile

@@ -1,42 +0,0 @@
-FROM ubuntu:22.04 AS base
-
-FROM base AS builder
-
-ENV DEBIAN_FRONTEND noninteractive
-
-RUN apt-get update && \
-    apt-get install -y \
-            build-essential \
-            cmake \
-            curl \
-            git \
-            libgnutls28-dev \
-            uuid-dev
-
-# Setup language environment
-ENV LC_ALL en_US.UTF-8
-ENV LANG en_US.UTF-8
-ENV LANGUAGE en_US.UTF-8
-
-# Add source directory
-ADD .. /root/code/
-WORKDIR /root/code/
-
-# Setup Rust
-RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs > rustup.sh && \
-    sh rustup.sh -y --profile minimal --default-toolchain stable --component rust-docs
-
-# Build Taskwarrior
-RUN git clean -dfx && \
-    git submodule init && \
-    git submodule update && \
-    cmake -S . -B build -DCMAKE_BUILD_TYPE=Release . && \
-    cmake --build build -j 8
-
-FROM base AS runner
-
-# Install Taskwarrior
-COPY --from=builder /root/code/build/src/task /usr/local/bin
-
-# Initialize Taskwarrior
-RUN ( echo "yes" | task ) || true

misc/README.md

@@ -1,3 +0,0 @@
-# misc/
-
-This directory contains bits and bobs that do not belong elsewhere.

performance/.gitignore

@@ -0,0 +1,3 @@
+*.data
+*.rc
+export.json

performance/CMakeLists.txt

@@ -1,9 +1,6 @@
-cmake_minimum_required (VERSION 3.22)
+cmake_minimum_required (VERSION 3.0)
 
-configure_file(compare_runs.py compare_runs.py COPYONLY)
-configure_file(load load)
-configure_file(run_perf run_perf)
-
-add_custom_target (performance ${CMAKE_BINARY_DIR}/performance/run_perf
+add_custom_target (performance ./run_perf
                                DEPENDS task_executable
-                               WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/performance)
+                               WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}/performance)
+

performance/compare_runs.py

@@ -29,13 +29,10 @@ def parse_perf(input):
         tests[command] = []
 
         # Parse concatenated run_perf output
-        for i in re.findall(
-            "^  - task %s\\.\\.\\.\n"
-            "Perf task ([^ ]+) ([^ ]+) ([^ ]+) (.+)$" % command,
-            input,
-            re.MULTILINE,
-        ):
-            info = i[0:3] + ({k: v for k, v in (i.split(":") for i in i[-1].split())},)
+        for i in re.findall("^  - task %s\.\.\.\n"
+                            "Perf task ([^ ]+) ([^ ]+) ([^ ]+) (.+)$"
+                            % command, input, re.MULTILINE):
+            info = i[0:3] + ({k:v for k, v in (i.split(":") for i in i[-1].split())},)
             pt = TaskPerf(*info)
             tests[command].append(pt)
     return tests
@@ -64,14 +61,8 @@ with open(sys.argv[2], "r") as fh:
     tests_cur = parse_perf(fh.read())
     best_cur = get_best(tests_cur)
 
-print(
-    "Previous: %s (%s)"
-    % (tests_prev[COMMANDS[0]][0].version, tests_prev[COMMANDS[0]][0].commit)
-)
-print(
-    "Current:  %s (%s)"
-    % (tests_cur[COMMANDS[0]][0].version, tests_cur[COMMANDS[0]][0].commit)
-)
+print("Previous: %s (%s)" % (tests_prev[COMMANDS[0]][0].version, tests_prev[COMMANDS[0]][0].commit))
+print("Current:  %s (%s)" % (tests_cur[COMMANDS[0]][0].version, tests_cur[COMMANDS[0]][0].commit))
 
 for test in COMMANDS:
     print("# %s:" % test)
@@ -85,9 +76,7 @@ for test in COMMANDS:
         else:
             percentage = "0%"
 
-        pad = max(
-            map(len, (k, best_prev[test][k], best_cur[test][k], diff, percentage))
-        )
+        pad = max(map(len, (k, best_prev[test][k], best_cur[test][k], diff, percentage)))
         out[0] += " %s" % k.rjust(pad)
         out[1] += " %s" % best_prev[test][k].rjust(pad)
         out[2] += " %s" % best_cur[test][k].rjust(pad)

performance/load

@@ -14,7 +14,7 @@ if (open my $fh, '>', 'perf.rc')
   close $fh;
 }
 
-my $filename = '${CMAKE_SOURCE_DIR}/performance/sample-text.txt';
+my $filename = 'sample-text.txt';
 open(my $fh, '<:encoding(UTF-8)', $filename)
   or die "Could not open file '$filename' $!";
 
@@ -31,18 +31,18 @@ while (my $line = <$fh>)
   if ($. % 20 == 19)
   {
     my $anno_id = $id - 1;
-    qx{${CMAKE_BINARY_DIR}/src/task rc:perf.rc rc.gc=off $anno_id annotate $line};
+    qx{../src/task rc:perf.rc rc.gc=off $anno_id annotate $line};
     print "[$.] task rc:perf.rc rc.gc=off $anno_id annotate $line\n" if $?;
   }
   elsif ($. % 4 == 1)
   {
-    qx{${CMAKE_BINARY_DIR}/src/task rc:perf.rc rc.gc=off add $line};
+    qx{../src/task rc:perf.rc rc.gc=off add $line};
     print "[$.] task rc:perf.rc rc.gc=off add $line\n" if $?;
     ++$id;
   }
   else
   {
-    qx{${CMAKE_BINARY_DIR}/src/task rc:perf.rc rc.gc=off log $line};
+    qx{../src/task rc:perf.rc rc.gc=off log $line};
     print "[$.] task rc:perf.rc rc.gc=off log $line\n" if $?;
   }
 }

performance/run_perf

@@ -1,22 +1,22 @@
 #! /bin/bash
 
 echo 'Performance: setup'
-rm -f ./taskchampion.sqlite3
-if [[ -e ./data/taskchampion.sqlite3 ]]
+rm -f ./pending.data ./completed.data ./undo.data ./backlog.data perf.rc
+if [[ -e data/pending.data && -e data/completed.data ]]
 then
-  echo '  - Using existing data.'
+  echo '  - Using existing data'
   cp data/* .
 else
-  echo '  - Loading data. This step will take several minutes.'
+  echo '  - This step will take several minutes'
   ./load
   mkdir -p data
-  cp taskchampion.sqlite3 perf.rc data
+  cp *.data perf.rc data
 fi
 
 # Allow override.
 if [[ -z $TASK ]]
 then
-  TASK=${CMAKE_BINARY_DIR}/src/task
+  TASK=../src/task
 fi
 
 # Run benchmarks.
@@ -45,8 +45,9 @@ $TASK rc.debug:1 rc:perf.rc export >/dev/null 2>&1
 $TASK rc.debug:1 rc:perf.rc export 2>&1 >export.json | grep "Perf task"
 
 echo '  - task import...'
-rm -f ./taskchampion.sqlite3
-$TASK rc.debug:1 rc:perf.rc import ${CMAKE_SOURCE_DIR}/performance/export.json 2>&1 | grep "Perf task"
+rm -f ./pending.data ./completed.data ./undo.data ./backlog.data
+$TASK rc.debug:1 rc:perf.rc import export.json 2>&1 | grep "Perf task"
 
 echo 'End'
 exit 0
+

performance/sample-text.txt

@@ -3963,7 +3963,7 @@ GLOUCESTER  Give me the letter, sir.
 EDMUND  I shall offend, either to detain or give it. The contents, as in part I understand them, are to blame.
 GLOUCESTER  Lets see, lets see.
 EDMUND  I hope, for my brothers justification, he wrote this but as an essay or taste of my virtue.
-GLOUCESTER  This policy and reverence of age makes the world bitter to the best of our times, keeps our fortunes from us till our oldness cannot relish them. I begin to find an idle and fond bondage in the oppression of aged tyranny, who sways, not as it hath power, but as it is suffered. Come to me, that of this I may speak more. If our father would sleep till I waked him, you should enjoy half his revenue for ever, and live the beloved of your brother,
+GLOUCESTER  This policy and reverence of age makes the world bitter to the best of our times, keeps our fortunes from us till our oldness cannot relish them. I begin to find an idle and fond bondage in the oppression of aged tyranny, who sways, not as it hath power, but as it is suffered. Come to me, that of this I may speak more. If our father would sleep till I waked him, you should enjoy half his revenue for ever, and live the beloved of your brother, 
 EDMUND  It was not brought me, my lord, theres the cunning of it, I found it thrown in at the casement of my closet.
 GLOUCESTER  You know the character to be your brothers?
 EDMUND  If the matter were good, my lord, I durst swear it were his, but, in respect of that, I would fain think it were not.

scripts/CMakeLists.txt

@@ -1,4 +1,4 @@
-cmake_minimum_required (VERSION 3.22)
+cmake_minimum_required (VERSION 3.0)
 install (DIRECTORY bash fish vim hooks
          DESTINATION ${TASK_DOCDIR}/scripts)
 install (FILES zsh/_task
@@ -8,3 +8,4 @@ install (DIRECTORY add-ons
          FILE_PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE
                           GROUP_READ             GROUP_EXECUTE
                           WORLD_READ             WORLD_EXECUTE)
+

scripts/add-ons/update-holidays.pl

@@ -221,3 +221,4 @@ if (open my $fh, '>:utf8', $file)
 exit 0;
 
 ################################################################################
+

scripts/fish/task.fish

@@ -123,10 +123,6 @@ function __fish.task.need_to_complete.config
   contains (__fish.task.current.command) 'config' 'show'
 end
 
-function __fish.task.need_to_complete.context
-  contains (__fish.task.current.command) 'context'
-end
-
 function __fish.task.need_to_complete.filter
   __fish.task.before_command
 end
@@ -221,10 +217,6 @@ function __fish.task.list.config
   task _config
 end
 
-function __fish.task.list.context
-  task _context
-end
-
 function __fish.task.list.depends
   __fish.task.list.id with_description
 end
@@ -295,9 +287,8 @@ end
 
 function __fish.task.list.tag
   set -l tags (task _tags)
-  printf '+%s\n' $tags
-  # compatibility, older fish won't allow - in format
-  printf ' %s\n' $tags | tr ' ' '-'
+  printf -- '+%s\n' $tags
+  printf -- '-%s\n' $tags
 end
 
 function __fish.task.list.task
@@ -355,10 +346,10 @@ end
 # static variables that won't changes even when taskw's data is modified
 set __fish_task_static_commands_with_desc (__fish.task.zsh commands | sort | string collect)
 set __fish_task_static_commands (echo -e $__fish_task_static_commands_with_desc | cut -d '	' -f 1 | string collect)
-set __fish_task_static_command_mods (printf '%s\n' 'add' 'annotate' 'append' 'delete' 'done' 'duplicate' 'log' 'modify' 'prepend' 'start' 'stop' | string collect)
-set __fish_task_static_mod (printf '%s\n' 'before' 'after' 'over' 'under' 'none' 'is' 'isnt' 'has' 'hasnt' 'startswith' 'endswith' 'word' 'noword' | string collect)
-set __fish_task_static_status (printf '%s\tstatus\n' 'pending' 'completed' 'deleted' 'waiting' | string collect)
-set __fish_task_static_priority (printf '%s\n' 'H\tHigh' 'M\tMiddle' 'L\tLow' | string collect)
+set __fish_task_static_command_mods (printf -- '%s\n' 'add' 'annotate' 'append' 'delete' 'done' 'duplicate' 'log' 'modify' 'prepend' 'start' 'stop' | string collect)
+set __fish_task_static_mod (printf -- '%s\n' 'before' 'after' 'over' 'under' 'none' 'is' 'isnt' 'has' 'hasnt' 'startswith' 'endswith' 'word' 'noword' | string collect)
+set __fish_task_static_status (printf -- '%s\tstatus\n' 'pending' 'completed' 'deleted' 'waiting' | string collect)
+set __fish_task_static_priority (printf -- '%s\n' 'H\tHigh' 'M\tMiddle' 'L\tLow' | string collect)
 
 set __fish_task_static_freq 'daily:Every day' \
                             'day:Every day' \
@@ -373,17 +364,17 @@ set __fish_task_static_freq 'daily:Every day' \
                             'yearly:Every year' \
                             'biannual:Every two years' \
                             'biyearly:Every two years'
-set __fish_task_static_freq (printf '%s\n' $__fish_task_static_freq | sed 's/:/\t/' | string collect)
+set __fish_task_static_freq (printf -- '%s\n' $__fish_task_static_freq | sed 's/:/\t/' | string collect)
 set __fish_task_static_freq_numeric 'd:days' \
                                     'w:weeks' \
                                     'q:quarters' \
                                     'y:years'
-set __fish_task_static_freq_numeric (printf '%s\n' $__fish_task_static_freq_numeric | sed 's/:/\t/' | string collect)
+set __fish_task_static_freq_numeric (printf -- '%s\n' $__fish_task_static_freq_numeric | sed 's/:/\t/' | string collect)
 set __fish_task_static_freq_numeric 'd:days' \
                                     'w:weeks' \
                                     'q:quarters' \
                                     'y:years'
-set __fish_task_static_freq_numeric (printf '%s\n' $__fish_task_static_freq_numeric | sed 's/:/\t/' | string collect)
+set __fish_task_static_freq_numeric (printf -- '%s\n' $__fish_task_static_freq_numeric | sed 's/:/\t/' | string collect)
 set __fish_task_static_dates 'today:Today' \
                              'yesterday:Yesterday' \
                              'tomorrow:Tomorrow' \
@@ -415,7 +406,7 @@ set __fish_task_static_dates 'today:Today' \
                              'midsommarafton:Midsommarafton' \
                              'later:Later' \
                              'someday:Some Day'
-set __fish_task_static_dates (printf '%s\n' $__fish_task_static_dates | sed 's/:/\t/' | string collect)
+set __fish_task_static_dates (printf -- '%s\n' $__fish_task_static_dates | sed 's/:/\t/' | string collect)
 set __fish_task_static_reldates 'hrs:n hours' \
                                 'day:n days' \
                                 # '1st:first' \
@@ -423,7 +414,7 @@ set __fish_task_static_reldates 'hrs:n hours' \
                                 # '3rd:third' \
                                 # 'th:4th, 5th, etc.' \
                                 'wks:weeks'
-set __fish_task_static_reldates (printf '%s\n' $__fish_task_static_reldates | sed 's/:/\t/' | string collect)
+set __fish_task_static_reldates (printf -- '%s\n' $__fish_task_static_reldates | sed 's/:/\t/' | string collect)
 # the followings are actually not used for autocomplete, but to retrieve friendly description that aren't present in internal command
 set  __fish_task_static_attr_desc_keys 'description' 'status' 'project' \
                                           'priority' 'due' 'recur' \
@@ -438,7 +429,6 @@ set  __fish_task_static_attr_desc_vals 'Task description text' 'Status of task -
 
 # fish's auto-completion when multiple `complete` have supplied with '-k' flag, the last will be displayed first
 __fish.task.complete config
-__fish.task.complete context
 __fish.task.complete attr_value
 __fish.task.complete attr_name
 __fish.task.complete tag

scripts/hooks/README

@@ -24,3 +24,4 @@ Expected Permissions
 Interface
   Each hook script has a unique interface. This is documented in the example
   scripts here.
+

scripts/hooks/on-exit.shadow-file

@@ -22,8 +22,9 @@ SHADOW_FILE=$(task _get rc.shadow.file)
 #   rc.detection=off       Disables terminal size detection
 #   rc.gc=off              Disables GC, thus not changing IDs unexpectedly
 #   rc.color=off           Disable color in the shadow file
+#   rc.locking=off         Disable file locking, to prevent race condition
 #   rc.hooks=off           Disable hooks, to prevent race condition
-task $SHADOW_COMMAND rc.detection=off rc.gc=off rc.color=off rc.hooks=off > $SHADOW_FILE 2>/dev/null
+task $SHADOW_COMMAND rc.detection=off rc.gc=off rc.color=off rc.locking=off rc.hooks=off > $SHADOW_FILE 2>/dev/null
 if [[ $? != 0 ]]
 then
   echo Could not create $SHADOW_FILE
@@ -32,3 +33,4 @@ fi
 
 echo Shadow file $SHADOW_FILE updated.
 exit 0
+

scripts/hooks/on-launch

@@ -14,3 +14,4 @@ echo 'on-launch'
 # - 0:     JSON ignored, non-JSON is feedback.
 # - non-0: JSON ignored, non-JSON is error.
 exit 0
+