Tasks: Spawn in Center Terminal

[baldwindavid]

Check for existing issues

• Completed

Describe the feature

The recently released #9064 is super-nice to run things like a "Test Under Cursor" task in the "dock".

"space t": ["task::Spawn", { "task_name": "Test Under Cursor" }],

However, another use case that I'd like to run as a task is posted in #9067

I'm simulating a netrw-ish experience by opening in a file explorer (ya for yazi explorer in this example) in a center terminal with...

"-": [
  "workspace::SendKeystrokes",
  ": c r p enter : new center terminal enter ya space cmd-v enter"
],

This works, but would be much cleaner using this "task_name" argument in a keybinding.

"-": ["task::Spawn", { "task_name": "List Files" }],

The issue is that this opens in the "dock" rather than the current pane.

I think it would be nice if a target could be specified alongside the task name with something like...

"-": ["task::Spawn", { "task_name": "List Files", "target": "center" }],

By default this "target" could be "dock". I suppose this "target" could instead be specified within the task. This would limit the flexibility a bit, but maybe that's the way to go to avoid spreading task options across both the task and the keybinding.

It appears this request is also noted in a comment within a discussion at #8485 (reply in thread)

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[osiewicz]

This would limit the flexibility a bit, but maybe that's the way to go to avoid spreading task options across both the task and the keybinding.

Or, going the other way: Task::Spawn could accept subset of task definition and override them at spawn
A pretty dummy example:
given a definition:

{
"label": "My task",
"command": "echo",
"args": ["/bin"]
}

and a binding:
"-": ["task::Spawn", { "task_name": "My task", "command": "ls"}],

When using keybinding, command field of the original task definition would be overridden with "ls".
Naturally, you may choose to override just a subset of fields (or no fields at all).

[baldwindavid]

@osiewicz That sounds like a slick and consistent way to do it. A few related notes:

• TIL that either "command" or "cmd" can be specified in tasks.json
• I wonder about the consistency of the task being named "label" in tasks.json, but "task_name" in the keybinding. Supposing these parameters can be overriden via keybinding, I don't think "task_name" is something that one would override. All that is to say, would it be simpler to make those overrides an optional third argument and the task name not in an object at all? (e.g. "-": ["task::Spawn", "My task", {"cmd": "ls"}],)
• Digressing here but, ultimately, it would be real nice if Zed someday were to support a target of the currently selected text. For example, if we wanted to, say, rewrap selected text to 80 characters...

  {
    "label": "Reflow",
    "target": "$ZED_SELECTED_TEXT",
    "command": "$ZED_SELECTED_TEXT | fmt -w 80"
  },

I would note that the $ZED_SELECTED_TEXT doesn't seem to account for multi-cursor at the moment. For reference, Helix has these commands that have similar behavior, but on all current selections...

| `:insert-output` | Run shell command, inserting output before each selection. |
| `:append-output` | Run shell command, appending output after each selection. |
| `:pipe` | Pipe each selection to the shell command. |
| `:pipe-to` | Pipe each selection to the shell command, ignoring output. |
| `:run-shell-command`, `:sh` | Run a shell command |

[osiewicz]

Re:

1. Whoops, actually I was writing it off the top of my head; cmd is not a thing, sorry. :/
2. Yeah, good point (though I guess we do need to store task_name in the object in the end); I think it may look like:
   "-": ["task::Spawn", { "task_name": "My task", "overrides": {"command": "ls"}}],
3. Yeah, the story around SELECTED_TEXT is still a bit rough. Right now we're more so focused on integrating with extensions. I think some way to pipe the output back into the editor may be cool, but I'd rather not have us do that right now and extend task capabilities as needed.

[baldwindavid]

1. Oh, ha, I actually tried it quickly and thought it worked, but see that it didn't actually save so was using the original.
2. and 3. 👍