task: Add task contexts

[osiewicz]

This PR supplements tasks with additional environment variables; ideally we'll be able to write a task like:
cargo test -p $ZED_CURRENT_PACKAGE -- $ZED_CURRENT_FUNCTION

• Flesh out multibuffer interactions
• Add ZED_SYMBOL detection based on tree-sitter queries
• Add release note and demo
• Figure out a solution for rerun dilemma - should task: rerun reevaluate contexts for tasks?

This PR introduced the following variables:

• ZED_COLUMN - current line column
• ZED_ROW - current line row
  and the following, which are available for buffers with associated files:
• ZED_WORKTREE_ROOT - absolute path to the root of the current worktree.
• ZED_FILE - absolute path to the file
• ZED_SYMBOL - currently selected symbol; should match the last symbol shown in a symbol breadcrumb (e.g. mod tests > fn test_task_contexts should be equal to ZED_SYMBOL of test_task_contexts). Note that this isn't necessarily a test function or a function at all.

Also, you can use them in cwd field of definitions (note though that we're using https://docs.rs/subst/latest/subst/#features for that, so don't expect a full shell functionality to work); the syntax should match up with your typical Unix shell.

Release Notes:

• Added task contexts, which are additional environment variables set by Zed for task execution; task content is dependent on the state of the editor at the time the task is spawned.

[baldwindavid]

Nice. I'm assuming a future PR will then add a ZED_CURRENT_LINE_NUMBER along with the ZED_CURRENT_FILE from this PR?

The thing I'm most looking forward to is being able to do things like mix test $ZED_CURRENT_FILE:$ZED_CURRENT_LINE_NUMBER and git blame -L $ZED_CURRENT_LINE_NUMBER $ZED_CURRENT_FILE

[osiewicz]

Hey, thanks for the suggestion! I think we can add col/row in this PR as well.

[baldwindavid]

That would be amazing. Filename and line number are definitely the keys for me.

As an aside, there's some similar functionality open in a PR over on helix. Here are a few that they're considering that might be helpful in the future in Zed...

| `%{basename}`   | The name and extension of the currently focused file. |
| `%{filename}`   | The absolute path of the currently focused file. |
| `%{dirname}`    | The absolute path of the parent directory of the currently focused file. |
| `%{cwd}`        | The absolute path of the current working directory of Helix. |
| `%{linenumber}` | The line number where the primary cursor is positioned. |
| `%{selection}`  | The text selected by the primary cursor. |

[osiewicz]

The task dilemma from PR description comes down to this: when you run a task that uses a variable from a context, should task: rerun use the same context or a different one?
If it were to reuse the same context, moving to a different file or even a different line and spawning a task via task: rerun would still spawn identical process to the one that was ran last. This is cool when you're fixing up an unit test (as you want to run the same test over and over), but it's not necessarily ideal if you were to move to the next test to fix; you'd have to spawn a task via a modal to "start" the rerun cycle.
To alleviate that, together with @Anthony-Eid we added a parameter to Rerun action which controls whether the context is reevaluated on task rerun or not.

[baldwindavid]

added a parameter to Rerun action which controls whether the context is reevaluated on task rerun or not.

@osiewicz Seems reasonable. This is probably a question for a different PR (i.e. could leverage the param here), but I do wonder if this could be a different command name altogether such as:

• Rerun: This suggests to me that the same context would be used
• Run Last Command/Task: This suggests to me that a different context would be used, but the same command

[baldwindavid]

Eh, I don't really think "Rerun" and "Run Last *" like I mentioned is clear enough so 🤷
Point being that maybe there are some words that are clearer that could be separate commands (e.g. "Rerun" and "Respawn"). Regardless, how you have it seems like a great way to go right now.

[osiewicz]

I am gonna follow up in other PRs to let folks play with it on nightly. Thank you @Anthony-Eid for pairing and @baldwindavid for your incredibly valuable feedback - please don't be shy to share more in the future PRs :)

[baldwindavid]

🥳 @osiewicz The work here is greatly appreciated. This will unlock a ton of potential workflows. Thanks so much.