Files
zed/crates/cli/src/cli.rs
Mateo Noel Rabines 4b489f4ce9 cli: Add --reuse flag for replacing workspace in existing window (#38131)
Closes #ISSUE 

it is was still in
[discussion](https://github.com/zed-industries/zed/discussions/37983)

Release Notes:

- Added: `--reuse` (`-r`) CLI flag to replace the workspace in an
existing window instead of opening a new one

This PR adds a new `--reuse` (`-r`) CLI flag that allows users to
replace the workspace in an existing Zed window instead of opening a new
one or adding files to the current workspace.

### What it does

The `--reuse` flag finds an available local workspace window and
replaces its workspace with the newly specified paths. This provides a
third workspace opening mode alongside the existing `--add` and `--new`
flags.

### Implementation Details

- **CLI Flag**: Added `--reuse` (`-r`) flag with proper mutual exclusion
with `--add` and `--new`
- **Window Replacement**: Uses the existing `replace_window` option in
`workspace::OpenOptions`
- **Window Selection**: Reuses the first available local workspace
window
- **Fallback Behavior**: When no existing windows are found, creates a
new window
- **Test Coverage**: Added comprehensive test for the reuse
functionality

### Behavior

- `zed -r file.txt` - Replaces the workspace in an available window with
`file.txt`
- If no windows are open, creates a new window (same as default
behavior)
- Mutually exclusive with `-a/--add` and `-n/--new` flags
- Works with multiple files and directories

### Files Changed

- `crates/cli/src/cli.rs` - Added `reuse` field to `CliRequest::Open`
- `crates/cli/src/main.rs` - Added CLI argument definition and parsing
- `crates/zed/src/zed/open_listener.rs` - Implemented reuse logic and
added tests
- `crates/zed/src/zed/windows_only_instance.rs` - Updated for Windows
compatibility

### Testing

-  Unit tests pass
-  Manual testing confirms expected behavior:
  - Works when no windows are open
  - Replaces workspace in existing window
  - Maintains compatibility with existing `-a` and `-n` flags
  - Proper help text display


## Manual testing

#### In this first video we do a couple of tests: 

* **1**: What happens if we use the -r flag when there are no windows
open?
        - works as expected. It opens the files in a new window.
        
* **2**: Does it work as expected if there is already a window open.
Does it overrides the workspace?
- yes it does. When opening a different file it overrides the current
window instead of creating a new one.
        
* **3**: Does the -n flag still works as expected?
        - yes, it creates the project in a new window

* **4**: What about the -a flag?
       - yes, on the last accessed page 
       
* **5**: we do the replace command. It overrides the first opened
window, do we want this behavior?
- It is good enough that it overrides one of the opened windows with the
new project. It still makes the user automatically go to the window with
the specified files

* **6**: we use the -r command again replacing the workspace with a new
one.
       - this indeed worked as expected


https://github.com/user-attachments/assets/f1cd7f4b-f4af-4da2-a755-c0be7ce96c0d


#### In here the we check how the --help flag now displays the new
command. (Description was later updated)


https://github.com/user-attachments/assets/a8a7a288-d926-431b-a9f9-a8c3d909a2ec
2025-10-20 22:41:13 -06:00

37 lines
997 B
Rust

use collections::HashMap;
pub use ipc_channel::ipc;
use serde::{Deserialize, Serialize};
#[derive(Serialize, Deserialize)]
pub struct IpcHandshake {
pub requests: ipc::IpcSender<CliRequest>,
pub responses: ipc::IpcReceiver<CliResponse>,
}
#[derive(Debug, Serialize, Deserialize)]
pub enum CliRequest {
Open {
paths: Vec<String>,
urls: Vec<String>,
diff_paths: Vec<[String; 2]>,
wsl: Option<String>,
wait: bool,
open_new_workspace: Option<bool>,
reuse: bool,
env: Option<HashMap<String, String>>,
user_data_dir: Option<String>,
},
}
#[derive(Debug, Serialize, Deserialize)]
pub enum CliResponse {
Ping,
Stdout { message: String },
Stderr { message: String },
Exit { status: i32 },
}
/// When Zed started not as an *.app but as a binary (e.g. local development),
/// there's a possibility to tell it to behave "regularly".
pub const FORCE_CLI_MODE_ENV_VAR_NAME: &str = "ZED_FORCE_CLI_MODE";