ZED_WORKTREE_ROOT should always point to a directory

[notpeter]

Check for existing issues

• Completed

Describe the bug / provide steps to reproduce it

Steps to reproduce:

1. Open your Zed tasks.json and add the following:

   {
     "label": "zed env",
     "command": "env | grep ZED"
   },

2. Cmd-P, task: spawn, select zed env at the bottom of the list.
3. Note:

   ZED_WORKTREE_ROOT=/Users/peter/.config/zed/tasks.json

Documentation suggests this variable will point to a folder, which I believe makes sense:

zed/docs/src/tasks.md

Line 84 in 86f5bb1

- `ZED_WORKTREE_ROOT`: absolute path to the root of the current worktree. (e.g. `/Users/my-user/path/to/project`)

Proposal: Behavior of ZED_WORKTREE_ROOT should match that default behavior of cwd which was improved in #22004 to not point at a file when spawned from a buffer that is outside of worktree (like the tasks.json example above).

This makes it possible to spawn other applications into the correct working directory, even when that must be passed an argument, not just implicitly inherited from cwd/$PWD.

For example:

  {
    "label": "lazygit",
    "command": "alacritty -o 'window.startup_mode=\"SimpleFullscreen\"' --working-directory ${ZED_WORKTREE_ROOT} --command lazygit",
    "hide": "always"
  },

This does not work: cd /tmp; alacritty (working directory defaults to ~)
This does work: alacritty --working-directory=/tmp

Originally reported by @VOID404 here:

• Tasks unexpectedly try to use the tasks.json file (or the keymap.json file) as a **current working directory** (it's not a directory, it's a file!!) #20060 (comment)

Zed Version and System Specs

Zed: v0.170.0 (Zed Nightly af1a3cb)
OS: macOS 14.7.0
Memory: 64 GiB
Architecture: aarch64

If applicable, add screenshots or screencasts of the incorrect state / behavior

No response

If applicable, attach your Zed.log file to this issue.

N/A

[aborg-dev]

If no one is already working on this, I would love to try to implement this behavior.

In my understanding we need to retrieve the worktree of the project that is opened in Zed and then use the newly created function root_dir [1] to get the value for ZED_WORKTREE_ROOT.

Let me know if I missed something!

[1]

zed/crates/worktree/src/worktree.rs

Line 2668 in 4445679

pub fn root_dir(&self) -> Option<Arc<Path>> {

[aborg-dev]

I've created the PR #23150 just to start the conversation about the desired behavior.

In this first naive implementation, when the out-of-tree tasks.json is selected, the ZED_WORKTREE_ROOT is not set because the root_dir is not defined.

In my understanding, we want to return the root directory of the currently "active project".

At the moment, BasicContextProvider::build_context does not have any information about the active project, so to get this info we will need to plumb it through.

Before I do this, though, can someone confirm that there is only one active project at a time? And are there plans for having more then one active project in the single Zed instance in the future?

[osiewicz]

Detached files are a pretty gnarly edge case in general.
There can be multiple projects, as each one roughly corresponds to an open Zed window. There'll be only one project per workspace though.
A quick-and-dirty solution IMHO to the root_dir problem is to fall back to taking the parent of ZED_FILE when root_dir is not available.

[aborg-dev]

Detached files are a pretty gnarly edge case in general. There can be multiple projects, as each one roughly corresponds to an open Zed window. There'll be only one project per workspace though.

Just to make sure I have all the terminology/assumptions correct:

• Window == Workspace - Full separate IDE instance, has panes, docks, terminal, etc.
• Project - Zed representation of environment for editing a particular folder on the filesystem. Root directory is a path to that folder
• Workspace might be either empty or have a particular project activated in it
• Worktree - A set of files that belongs to a particular project
• Each file belongs to a worktree
• The out-of-tree files like keymap.json are handled as a separate worktree that does not belong to the active project, and it temporarily included in the Workspace

Did I get it roughly right?

In this case, it does seem like the concept of active project is well defined and it would be a reasonable target for newly spawned tasks.

A quick-and-dirty solution IMHO to the root_dir problem is to fall back to taking the parent of ZED_FILE when root_dir is not available.

Sure, I let me start with this to fix the immediate problem with ZED_WORKTREE_ROOT pointing to a file.

[osiewicz]

Yeah, that's mostly correct except for the last point; they're hidden worktrees. Each worktree is a distinct top-level directory in a project panel and out-of-tree files are handled the same way, except that they're not shown in the UI.
(I mentioned project panel since it's one piece of UI where project vs worktree distinction is apparent)