Tasks are using file parameters from previous runs

[pedrorolo]

Check for existing issues

• Completed

Describe the bug / provide steps to reproduce it

When running the same task a second time using Ctrol-Shift-T , the values from the old run for $ZED_FILE, and $ZED_ROW are used instead of the ones of the current context. Please notice that this might be desirable when reruning tasks with Ctrol-T.

Environment

Zed: v0.132.0 (Zed Preview)
OS: macOS 14.4.1
Memory: 8 GiB
Architecture: aarch64

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

No response

If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.

No response

[SomeoneToIgnore]

Please notice that this might be desirable when reruning tasks with Ctrol-T.

Exactly this.
If you want to rerun your tasks with the new context only, consider using an altered rerun flavor:

{
    "context": "Workspace",
    "bindings": {
        "alt-t": ["task::Rerun", { "reevaluate_context": true }]
    }
}

[pedrorolo]

This should be a default:

[
  {
    "context": "Workspace",
    "bindings": {
      "alt-shift-t": ["task::Spawn", { "reevaluate_context": true }]
    }
  }
]

[pedrorolo]

I suspect that from a product perspective what makes sense is to have revaluate_context true by default, and that alt-t should explicitly mark it as false. In most commands that use the context you will want to reevaluate it at every execution. @SomeoneToIgnore @JosephTLyons

[jessevdp]

This should be a default:

[
  {
    "context": "Workspace",
    "bindings": {
      "alt-shift-t": ["task::Spawn", { "reevaluate_context": true }]
    }
  }
]

This does not work.

The { "reevaluate_context": true } argument works as expected on task::Rerun. But it does not have any effect on task::Spawn.

Its explicitly defined on Rerun.

zed/crates/tasks_ui/src/modal.rs

Lines 42 to 47 in 5ef7591

	/// Controls whether the task context is reevaluated prior to execution of a task.
	/// If it is not, environment variables such as ZED_COLUMN, ZED_FILE are gonna be the same as in the last execution of a task
	/// If it is, these variables will be updated to reflect current state of editor at the time task::Rerun is executed.
	/// default: false
	#[serde(default)]
	pub reevaluate_context: bool,

And not on Spawn:

zed/crates/tasks_ui/src/modal.rs

Lines 25 to 31 in 5ef7591

	pub struct Spawn {
	#[serde(default)]
	/// Name of the task to spawn.
	/// If it is not set, a modal with a list of available tasks is opened instead.
	/// Defaults to None.
	pub task_name: Option<String>,
	}

---

I currently see no way to force re-evaluation of $ZED_FILE and $ZED_ROW etc on task::Spawn.

What's the mental model here?

If you task::Spawn the same task for a second time, is that equivalent to task::Rerun? How does one "spawn" a completely new instance?

---

PS. I did find the "ignore_previously_resolved": true setting for the tasks definition.

{
  "label": "RSpec: current file",
  "args": ["$ZED_FILE"],
  "command": "rspec --order defined --format doc --no-profile",
  "ignore_previously_resolved": true
}

But that breaks the ability to re-run a task without re-evaluating $ZED_FILE when using task::Rerun.

[SomeoneToIgnore]

I believe this should be improved in #10873, see #11026 (comment) for more details.

[jessevdp]

The screenshots shared here #11026 (comment) looks awesome! 🤩

I was indeed thinking that the mental model (UX) needed some improvements. Rather than the "hack" of "if I use the spawn modal -> it resets context, but when I use rerun it does not".

The mental model of Task Templates vs. Task "instances" works really well there I think. Awesome idea!

• Use the "task spawner/modal" to re-run a recent task
• Use the "task spawner/modal" to run a new instance of a task
• Re-run the last task

---

I'm curious @osiewicz, are there any plans to show the arguments for the task in the UI?

Say I have the following tasks defined:

[
  {
    "label": "rspec: single file",
    "args": ["$ZED_FILE"],
    "command": "rspec --order defined --format doc --no-profile",
  },
  {
    "label": "rspec: single line",
    "args": ["$ZED_FILE:$ZED_ROW"],
    "command": "rspec --order defined --format doc --no-profile",
  },
]

I'd want to be able to tell the difference between two recent instances of "RSpec: single line".

Note: $ZED_FILE resolves to an absolute path, but in the tasks UI a relative path would suffice (& be preferable of course).

[osiewicz]

Hey @jessevdp,
Yeah, it should be possible to inspect full command line of a task instance even in current Preview; we surface them in tooltips as follows:

Note though that if you were to run the same task twice, you'd only get one instance in your task history.

[jessevdp]

Ah I see.

I suppose that works well enough for the problem as described in this issue.

But I wonder if there would still be room for a proper “arguments” concept for tasks. Where a “template” could have arguments of different types: fillable through pre-defined variables like $ZED_EDITOR, or perhaps through user-input. (Related: #10838.)

Perhaps with some option to override defaulted values? (Though for the use case of running the file under cursor, less UI is better.)

If these arguments were first-class citizens, they could show up in the task selection UI too.

1. Spawn a task from a template
2. (Fill out the arguments, automatically if they reference ENV variables.)
3. … it runs …
4. Re-spawn a task (with stored argument context)

Just dreaming/spitballing a bit here. Do you think it’s a worthwhile idea? Would you like me to write it out further and create a separate issue?

[osiewicz]

I think that would be nice, yeah, but I don't think now is a good time to tackle that. We probably should sort out various wrinkles with tasks first (e.g. how they're gonna integrate with extensions). I'd rather have us focus on that for now and actually get tasks more to forefront of Zed experience and then see how common of a limitation the lack of user input is.
A separate issue definitely sounds like a good idea (tho maybe we could hijack #10838).