rename CLI to ta

cli/src/argparse/command.rs

@@ -49,10 +49,10 @@ mod test {
     #[test]
     fn test_version() {
         assert_eq!(
-            Command::from_argv(argv!["task", "version"]).unwrap(),
+            Command::from_argv(argv!["ta", "version"]).unwrap(),
             Command {
                 subcommand: Subcommand::Version,
-                command_name: s!("task"),
+                command_name: s!("ta"),
             }
         );
     }

cli/src/invocation/cmd/help.rs

@@ -19,12 +19,12 @@ mod test {
     #[test]
     fn test_summary() {
         let mut w = test_writer();
-        execute(&mut w, s!("task"), true).unwrap();
+        execute(&mut w, s!("ta"), true).unwrap();
     }
 
     #[test]
     fn test_long() {
         let mut w = test_writer();
-        execute(&mut w, s!("task"), false).unwrap();
+        execute(&mut w, s!("ta"), false).unwrap();
     }
 }

cli/src/usage.rs

@@ -42,7 +42,7 @@ impl Usage {
         writeln!(w, "USAGE:\n  {} [args]\n", command_name)?;
         writeln!(w, "TaskChampion subcommands:")?;
         for subcommand in self.subcommands.iter() {
-            subcommand.write_help(&mut w, summary)?;
+            subcommand.write_help(&mut w, command_name, summary)?;
         }
         writeln!(w, "Filter Expressions:\n")?;
         writeln!(
@@ -56,7 +56,7 @@ impl Usage {
             )
         )?;
         for filter in self.filters.iter() {
-            filter.write_help(&mut w, summary)?;
+            filter.write_help(&mut w, command_name, summary)?;
         }
         writeln!(w, "Modifications:\n")?;
         writeln!(
@@ -70,10 +70,10 @@ impl Usage {
             )
         )?;
         for modification in self.modifications.iter() {
-            modification.write_help(&mut w, summary)?;
+            modification.write_help(&mut w, command_name, summary)?;
         }
         if !summary {
-            writeln!(w, "\nSee `task help` for more detail")?;
+            writeln!(w, "\nSee `{} help` for more detail", command_name)?;
         }
         Ok(())
     }
@@ -108,13 +108,14 @@ pub(crate) struct Subcommand {
 }
 
 impl Subcommand {
-    fn write_help<W: Write>(&self, mut w: W, summary: bool) -> Result<()> {
+    fn write_help<W: Write>(&self, mut w: W, command_name: &str, summary: bool) -> Result<()> {
         if summary {
-            writeln!(w, "  task {} - {}", self.name, self.summary)?;
+            writeln!(w, "  {} {} - {}", command_name, self.name, self.summary)?;
         } else {
             writeln!(
                 w,
-                "  task {}\n{}",
+                "  {} {}\n{}",
+                command_name,
                 self.syntax,
                 indented(self.description, "    ")
             )?;
@@ -138,7 +139,7 @@ pub(crate) struct Filter {
 }
 
 impl Filter {
-    fn write_help<W: Write>(&self, mut w: W, summary: bool) -> Result<()> {
+    fn write_help<W: Write>(&self, mut w: W, _: &str, summary: bool) -> Result<()> {
         if summary {
             writeln!(w, "  {} - {}", self.syntax, self.summary)?;
         } else {
@@ -168,7 +169,7 @@ pub(crate) struct Modification {
 }
 
 impl Modification {
-    fn write_help<W: Write>(&self, mut w: W, summary: bool) -> Result<()> {
+    fn write_help<W: Write>(&self, mut w: W, _: &str, summary: bool) -> Result<()> {
         if summary {
             writeln!(w, "  {} - {}", self.syntax, self.summary)?;
         } else {

cli/tests/cli.rs

@@ -4,7 +4,7 @@ use std::fs;
 use std::process::Command;
 use tempfile::TempDir;
 
-// NOTE: This tests that the task binary is running and parsing arguments.  The details of
+// NOTE: This tests that the `ta` binary is running and parsing arguments.  The details of
 // subcommands are handled with unit tests.
 
 /// These tests force config to be read via TASKCHAMPION_CONFIG so that a user's own config file
@@ -17,7 +17,7 @@ fn test_cmd(dir: &TempDir) -> Result<Command, Box<dyn std::error::Error>> {
     )?;
 
     let config_filename = config_filename.to_str().unwrap();
-    let mut cmd = Command::cargo_bin("task")?;
+    let mut cmd = Command::cargo_bin("ta")?;
     cmd.env("TASKCHAMPION_CONFIG", config_filename);
     Ok(cmd)
 }

docs/src/config-file.md

@@ -1,6 +1,6 @@
 # Configuration
 
-The `task` command will work out-of-the-box with no configuration file, using default values.
+The `ta` command will work out-of-the-box with no configuration file, using default values.
 
 Configuration is read from `taskchampion.toml` in your config directory.
 On Linux systems, that directory is `~/.config`.

docs/src/debugging.md

@@ -1,9 +1,9 @@
 # Debugging
 
-Both `task` and `taskchampion-sync-server` use [env-logger](https://docs.rs/env_logger) and can be configured to log at various levels with the `RUST_LOG` environment variable.
+Both `ta` and `taskchampion-sync-server` use [env-logger](https://docs.rs/env_logger) and can be configured to log at various levels with the `RUST_LOG` environment variable.
 For example:
 ```shell
-$ RUST_LOG=taskchampion=trace task add foo
+$ RUST_LOG=taskchampion=trace ta add foo
 ```
 
 The output may provide valuable clues in debugging problems.

docs/src/reports.md

@@ -10,7 +10,7 @@ TaskChampion includes several "built-in" reports, as well as supporting custom r
 The `next` report is the default, and lists all pending tasks:
 
 ```text
-$ task
+$ ta
 Id Description              Active Tags              
 1  learn about TaskChampion        +next
 2  buy wedding gift         *      +buy
@@ -18,7 +18,7 @@ Id Description              Active Tags
 ```
 
 The `Id` column contains short numeric IDs that are assigned to pending tasks.
-These IDs are easy to type, such as to mark task 2 done (`task 2 done`).
+These IDs are easy to type, such as to mark task 2 done (`ta 2 done`).
 
 The `list` report lists all tasks, with a similar set of columns.
 

docs/src/sync-model.md

@@ -125,4 +125,4 @@ Without synchronization, its list of pending operations would grow indefinitely,
 So all replicas, even "singleton" replicas which do not replicate task data with any other replica, must synchronize periodically.
 
 TaskChampion provides a `LocalServer` for this purpose.
-It implements the `get_child_version` and `add_version` operations as described, storing data on-disk locally, all within the `task` binary.
+It implements the `get_child_version` and `add_version` operations as described, storing data on-disk locally, all within the `ta` binary.

docs/src/tags.md

@@ -4,7 +4,7 @@ Each task has a collection of associated tags.
 Tags are short words that categorize tasks, typically written with a leading `+`, such as `+next` or `+jobsearch`.
 
 Tags are useful for filtering tasks in reports or on the command line.
-For example, when it's time to continue the job search, `task +jobsearch` will show pending tasks with the `jobsearch` tag.
+For example, when it's time to continue the job search, `ta +jobsearch` will show pending tasks with the `jobsearch` tag.
 
 ## Allowed Tags
 

docs/src/task-sync.md

@@ -4,7 +4,7 @@ A single TaskChampion task database is known as a "replica".
 A replica "synchronizes" its local information with other replicas via a sync server.
 Many replicas can thus share the same task history.
 
-This operation is triggered by running `task sync`.
+This operation is triggered by running `ta sync`.
 Typically this runs frequently in a cron task.
 Synchronization is quick, especially if no changes have occurred.
 
@@ -14,10 +14,10 @@ Without periodic syncs, the storage space used for the task database will grow q
 By default, TaskChampion syncs to a "local server", as specified by the `server_dir` configuration parameter.
 Every replica sharing a task history should have precisely the same configuration for `server_origin`, `server_client_key`, and `encryption_secret`.
 
-Synchronizing a new replica to an existing task history is easy: begin with an empty replica, configured for the remote server, and run `task sync`.
+Synchronizing a new replica to an existing task history is easy: begin with an empty replica, configured for the remote server, and run `ta sync`.
 The replica will download the entire task history.
 
-It is possible to switch a single replica to a remote server by simply configuring for the remote server and running `task sync`.
+It is possible to switch a single replica to a remote server by simply configuring for the remote server and running `ta sync`.
 The replica will upload the entire task history to the server.
 Once this is complete, additional replicas can be configured with the same settings in order to share the task history.
 

docs/src/using-task-command.md

@@ -1,9 +1,9 @@
 # Using the Task Command
 
-The main interface to your tasks is the `task` command, which supports various subcommands such as `add`, `modify`, `start`, and `done`.
+The main interface to your tasks is the `ta` command, which supports various subcommands such as `add`, `modify`, `start`, and `done`.
 Customizable [reports](./reports.md) are also available as subcommands, such as `next`.
 The command reads a [configuration file](./config-file.md) for its settings, including where to find the task database.
 And the `sync` subcommand [synchronizes tasks with a sync server](./task-sync.md).
-You can find a list of all subcommands, as well as the built-in reports, with `task help`.
+You can find a list of all subcommands, as well as the built-in reports, with `ta help`.
 
 > NOTE: the `task` interface does not precisely match that of TaskWarrior.

docs/src/welcome.md

@@ -1,7 +1,7 @@
 # TaskChampion
 
 TaskChampion is a personal task-tracking tool.
-It works from the command line, with simple commands like `task add "fix the kitchen sink"`.
+It works from the command line, with simple commands like `ta add "fix the kitchen sink"`.
 It can synchronize tasks on multiple devices, and does so in an "offline" mode so you can update your tasks even when you can't reach the server.
 If you've heard of [TaskWarrior](https://taskwarrior.org/), this tool is very similar, but with some different design choices and greater reliability.
 
@@ -10,18 +10,18 @@ If you've heard of [TaskWarrior](https://taskwarrior.org/), this tool is very si
 > NOTE: TaskChampion is still in development and not yet feature-complete.
 > This section is limited to completed functionality.
 
-Once you've [installed TaskChampion](./installation.md), your interface will be via the `task` command.
+Once you've [installed TaskChampion](./installation.md), your interface will be via the `ta` command.
 Start by adding a task:
 
 ```shell
-$ task add learn how to use taskchampion
+$ ta add learn how to use taskchampion
 added task ba57deaf-f97b-4e9c-b9ab-04bc1ecb22b8
 ```
 
-You can see all of your pending tasks with `task next`, or just `task` for short:
+You can see all of your pending tasks with `ta next`, or just `ta` for short:
 
 ```shell
-$ task
+$ ta
  Id Description                    Active  Tags
  1  learn how to use taskchampion
 ```
@@ -29,13 +29,13 @@ $ task
 Tell TaskChampion you're working on the task, using the shorthand id:
 
 ```shell
-$ task start 1
+$ ta start 1
 ```
 
 and when you're done with the task, mark it as complete:
 
 ```shell
-$ task done 1
+$ ta done 1
 ```
 
 ## Synchronizing
@@ -44,7 +44,7 @@ Even if you don't have a server, it's a good idea to sync your task database per
 This acts as a backup and also enables some internal house-cleaning.
 
 ```shell
-$ task sync
+$ ta sync
 ```
 
 Typically sync is run from a crontab, on whatever schedule fits your needs.
@@ -57,7 +57,7 @@ server_client_key: "f8d4d09d-f6c7-4dd2-ab50-634ed20a3ff2"
 server_origin: "https://taskchampion.example.com"
 ```
 
-The next run of `task sync` will upload your task history to that server.
+The next run of `ta sync` will upload your task history to that server.
-Configuring another device identically and running `task sync` will download that task history, and continue to stay in sync with subsequent runs of the command.
+Configuring another device identically and running `ta sync` will download that task history, and continue to stay in sync with subsequent runs of the command.
 
 See [Usage](./using-task-command.md) for more detailed information on using TaskChampion.