tasks.md

  1# Tasks
  2
  3Zed supports ways to spawn (and rerun) commands using its integrated terminal to output the results. These commands can read a limited subset of Zed state (such as a path to the file currently being edited or selected text).
  4
  5```json
  6[
  7  {
  8    "label": "Example task",
  9    "command": "for i in {1..5}; do echo \"Hello $i/5\"; sleep 1; done",
 10    //"args": [],
 11    // Env overrides for the command, will be appended to the terminal's environment from the settings.
 12    "env": { "foo": "bar" },
 13    // Current working directory to spawn the command into, defaults to current project root.
 14    //"cwd": "/path/to/working/directory",
 15    // Whether to use a new terminal tab or reuse the existing one to spawn the process, defaults to `false`.
 16    "use_new_terminal": false,
 17    // Whether to allow multiple instances of the same task to be run, or rather wait for the existing ones to finish, defaults to `false`.
 18    "allow_concurrent_runs": false,
 19    // What to do with the terminal pane and tab, after the command was started:
 20    // * `always` — always show the task's pane, and focus the corresponding tab in it (default)
 21    // * `no_focus` — always show the task's pane, add the task's tab in it, but don't focus it
 22    // * `never` — do not alter focus, but still add/reuse the task's tab in its pane
 23    "reveal": "always",
 24    // What to do with the terminal pane and tab, after the command has finished:
 25    // * `never` — Do nothing when the command finishes (default)
 26    // * `always` — always hide the terminal tab, hide the pane also if it was the last tab in it
 27    // * `on_success` — hide the terminal tab on task success only, otherwise behaves similar to `always`
 28    "hide": "never",
 29    // Which shell to use when running a task inside the terminal.
 30    // May take 3 values:
 31    // 1. (default) Use the system's default terminal configuration in /etc/passwd
 32    //      "shell": "system"
 33    // 2. A program:
 34    //      "shell": {
 35    //        "program": "sh"
 36    //      }
 37    // 3. A program with arguments:
 38    //     "shell": {
 39    //         "with_arguments": {
 40    //           "program": "/bin/bash",
 41    //           "args": ["--login"]
 42    //         }
 43    //     }
 44    "shell": "system",
 45    // Whether to show the task line in the output of the spawned task, defaults to `true`.
 46    "show_summary": true,
 47    // Whether to show the command line in the output of the spawned task, defaults to `true`.
 48    "show_output": true
 49  }
 50]
 51```
 52
 53There are two actions that drive the workflow of using tasks: `task: spawn` and `task: rerun`.
 54`task: spawn` opens a modal with all available tasks in the current file.
 55`task: rerun` reruns the most recently spawned task. You can also rerun tasks from the task modal.
 56
 57By default, rerunning tasks reuses the same terminal (due to the `"use_new_terminal": false` default) but waits for the previous task to finish before starting (due to the `"allow_concurrent_runs": false` default).
 58
 59Keep `"use_new_terminal": false` and set `"allow_concurrent_runs": true` to allow cancelling previous tasks on rerun.
 60
 61## Task templates
 62
 63Tasks can be defined:
 64
 65- in the global `tasks.json` file; such tasks are available in all Zed projects you work on. This file is usually located in `~/.config/zed/tasks.json`. You can edit them by using the `zed: open tasks` action.
 66- in the worktree-specific (local) `.zed/tasks.json` file; such tasks are available only when working on a project with that worktree included. You can edit worktree-specific tasks by using the `zed: open local tasks` action.
 67- on the fly with [oneshot tasks](#oneshot-tasks). These tasks are project-specific and do not persist across sessions.
 68- by language extension.
 69
 70## Variables
 71
 72Zed tasks act just like your shell; that also means that you can reference environmental variables via sh-esque `$VAR_NAME` syntax. A couple of additional environmental variables are set for your convenience.
 73These variables allow you to pull information from the current editor and use it in your tasks. The following variables are available:
 74
 75- `ZED_COLUMN`: current line column
 76- `ZED_ROW`: current line row
 77- `ZED_FILE`: absolute path of the currently opened file (e.g. `/Users/my-user/path/to/project/src/main.rs`)
 78- `ZED_FILENAME`: filename of the currently opened file (e.g. `main.rs`)
 79- `ZED_DIRNAME`: absolute path of the currently opened file with file name stripped (e.g. `/Users/my-user/path/to/project/src`)
 80- `ZED_RELATIVE_FILE`: path of the currently opened file, relative to `ZED_WORKTREE_ROOT` (e.g. `src/main.rs`)
 81- `ZED_STEM`: stem (filename without extension) of the currently opened file (e.g. `main`)
 82- `ZED_SYMBOL`: currently selected symbol; should match the last symbol shown in a symbol breadcrumb (e.g. `mod tests > fn test_task_contexts`)
 83- `ZED_SELECTED_TEXT`: currently selected text
 84- `ZED_WORKTREE_ROOT`: absolute path to the root of the current worktree. (e.g. `/Users/my-user/path/to/project`)
 85- `ZED_CUSTOM_RUST_PACKAGE`: (Rust-specific) name of the parent package of $ZED_FILE source file.
 86
 87To use a variable in a task, prefix it with a dollar sign (`$`):
 88
 89```json
 90{
 91  "label": "echo current file's path",
 92  "command": "echo $ZED_FILE"
 93}
 94```
 95
 96You can also use verbose syntax that allows specifying a default if a given variable is not available: `${ZED_FILE:default_value}`
 97
 98These environmental variables can also be used in tasks' `cwd`, `args`, and `label` fields.
 99
100### Variable Quoting
101
102When working with paths containing spaces or other special characters, please ensure variables are properly escaped.
103
104For example, instead of this (which will fail if the path has a space):
105
106```json
107{
108  "label": "stat current file",
109  "command": "stat $ZED_FILE"
110}
111```
112
113Provide the following:
114
115```json
116{
117  "label": "stat current file",
118  "command": "stat",
119  "args": ["$ZED_FILE"]
120}
121```
122
123Or explicitly include escaped quotes like so:
124
125```json
126{
127  "label": "stat current file",
128  "command": "stat \"$ZED_FILE\""
129}
130```
131
132## Oneshot tasks
133
134The same task modal opened via `task: spawn` supports arbitrary bash-like command execution: type a command inside the modal text field, and use `opt-enter` to spawn it.
135
136The task modal persists these ad-hoc commands for the duration of the session, `task: rerun` will also rerun such tasks if they were the last ones spawned.
137
138You can also adjust the currently selected task in a modal (`tab` is the default key binding). Doing so will put its command into a prompt that can then be edited & spawned as a oneshot task.
139
140### Ephemeral tasks
141
142You can use the `cmd` modifier when spawning a task via a modal; tasks spawned this way will not have their usage count increased (thus, they will not be respawned with `task: rerun` and they won't have a high rank in the task modal).
143The intended use of ephemeral tasks is to stay in the flow with continuous `task: rerun` usage.
144
145## Custom keybindings for tasks
146
147You can define your own keybindings for your tasks via an additional argument to `task::Spawn`. If you wanted to bind the aforementioned `echo current file's path` task to `alt-g`, you would add the following snippet in your [`keymap.json`](./key-bindings.md) file:
148
149```json
150{
151  "context": "Workspace",
152  "bindings": {
153    "alt-g": ["task::Spawn", { "task_name": "echo current file's path" }]
154  }
155}
156```
157
158Note that these tasks can also have a 'target' specified to control where the spawned task should show up.
159This could be useful for launching a terminal application that you want to use in the center area:
160
161```json
162// In tasks.json
163{
164  "label": "start lazygit",
165  "command": "lazygit -p $ZED_WORKTREE_ROOT"
166}
167```
168
169```json
170// In keymap.json
171{
172  "context": "Workspace",
173  "bindings": {
174    "alt-g": [
175      "task::Spawn",
176      { "task_name": "start lazygit", "reveal_target": "center" }
177    ]
178  }
179}
180```
181
182## Binding runnable tags to task templates
183
184Zed supports overriding the default action for inline runnable indicators via workspace-local and global `tasks.json` file with the following precedence hierarchy:
185
1861. Workspace `tasks.json`
1872. Global `tasks.json`
1883. Language-provided tag bindings (default).
189
190To tag a task, add the runnable tag name to the `tags` field on the task template:
191
192```json
193{
194  "label": "echo current file's path",
195  "command": "echo $ZED_FILE",
196  "tags": ["rust-test"]
197}
198```
199
200In doing so, you can change which task is shown in the runnables indicator.
201
202## Keybindings to run tasks bound to runnables
203
204When you have a task definition that is bound to the runnable, you can quickly run it using [Code Actions](https://zed.dev/docs/configuring-languages?#code-actions) that you can trigger either via `editor: Toggle Code Actions` command or by the `cmd-.`/`ctrl-.` shortcut. Your task will be the first in the dropdown. The task will run immediately if there are no additional Code Actions for this line.