Subcommand

For git checkout, the subcommand checkout would have name: "checkout"

For npm install, the subcommand install would have name: ["install", "i"] as these two values both represent the same subcommand.

A CLI tool like aws is composed of many top-level subcommands (s3, ec2, eks…), each of which include child subcommands of their own.

A command like git commit accepts various flags and options, such as --message and --all. These Option objects would be included in the options field.

yarn workspace [name] with fuzzy search is way more useful since we can omit the npm package scope

fig settings uses fuzzy search to prevent having to add the autocomplete. prefix to each searched setting

const figSpec: Fig.Spec {
  name: "fig",
  subcommands: [
    {
      name: "settings",
      filterStrategy: "fuzzy",
      subcommands: [
        {
          name: "autocomplete.theme", // if a user writes `fig settings theme` it gets the correct suggestions
        },
        // ... other settings
      ]
    },
    // ... other fig subcommands
  ]
}

Suppose you have an internal CLI tool that wraps kubectl. Instead of copying the kubectl completion spec, you can include the spec at runtime.

{
  name: "kube",
  description: "a wrapper around kubectl"
  loadSpec: "kubectl"
}

In the aws completion spec, loadSpec is used to optimize performance. The completion spec is split into multiple files, each of which can be loaded separately.

{
  name: "s3",
  loadSpec: "aws/s3"
}

The python spec uses generateSpec to include thedjango-admin spec if django manage.py exists.

generateSpec: async (tokens, executeShellCommand) => {
   // Load the contents of manage.py
   const managePyContents = await executeShellCommand("cat manage.py");
   // Heuristic to determine if project uses django
   if (managePyContents.contains("django")) {
     return {
       name: "python",
       subcommands: [{ name: "manage.py", loadSpec: "django-admin" }],
     };
   }
 },

The -work option from the go spec is parsed as a single flag when parserDirectives.flagsArePosixNoncompliant is set to true. Normally, this would be chained and parsed as -w -o -r -k if flagsArePosixNoncompliant is not set to true.

The npm CLI has a subcommand called install. If we wanted to display some custom text like Install an NPM package 📦 we would set name: "install" and displayName: "Install an NPM package 📦"

For the git commit subcommand, the -m option has an insert value of -m '{cursor}'

"Your commit message"

A

😊

https://www.herokucdn.com/favicon.ico

fig://icon?type=file

This is used in the rm spec. Why? Because we don't want users to accidentally delete their files so we make it just a little bit harder…

Let's say a user has previously selected a suggestion at unix timestamp 1634087677: - If completion spec did not set a priority (Fig treats this as priority 50), its priority would change to 75 + 0.1634087677 = 75.1634087677; - If completion spec set a priority of 49 or less, its priority would change to 49 + 0.1634087677 = 49.1634087677; - If completion spec set a priority of 76 or more, its priority would change to 76 + 0.1634087677 = 76.1634087677; - If a user had never selected a suggestion, then its priority would just stay as is (or if not set, default to 50).

If you want your suggestions to always be: - at the top order, rank them 76 or above. - at the bottom, rank them 49 or below

The "-" suggestion is hidden in the cd spec. You will only see it if you type exactly cd -

'ls/filepathPreview'