zed

zed copied to clipboard

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_CURRENT_FUNCTION 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?

Release Notes:

• TODO

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

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

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. |

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.

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

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.

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 :)

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