![]() Closes #15966 This PR adds `Alt/Opt+Click` to expand or collapse a directory and all its contents. Context: The current `expand_entry` scans immediate child subdirectories if they aren’t loaded, while `expand_all_for_entry` scans the entire subtree. The latter takes longer, so we wait for it to complete to ensure accurate results. For full directory scan, instead of using `refresh_entries_for_paths(vec![path])`, which requires specifying all explicit paths to refresh, we use `add_path_prefix_to_scan`, which eliminates the need to list every path. Both methods internally call `reload_entries_for_paths`, which invokes `should_scan_directory`. This determines whether to scan deeper based on a path prefix match between the given directory and its subdirectories, returning `true` for `add_path_prefix_to_scan`. The existing code handles scanning, removing path prefixes after scans complete, and managing ignored directories. How it works (Expand): 1. Alt clicking on non-ignored closed directory, expands it and all its subdirectories, except ignored subdirectories. This helps while working on mono repos, where you might not want to expand dirs like `node_modules`, `dist`, etc or git submodules, when you expand any root dir. In example, `draft` and `posts` dir are ignored dir. [expand-1.webm](https://github.com/user-attachments/assets/07d3f724-0757-408f-b349-5beb4ee8440e) 2. Alt clicking on ignored closed directory, expands it and all its subdirectories. This is when you explicitly want to do it, on dirs like `node_modules`, `dist`, etc. In example, `dist` dir is ignored dir. [expand-2.webm](https://github.com/user-attachments/assets/99e55883-ab1a-4a9c-a0f0-48026991a922) 3. In case of auto folded subdirectories, expand all action will take precedence over it. That is, it will unfold all the subdirectories inside clicked dir. This is intentional, as user explicitly wants to reveal as much content as possible. (This is my personal opinion on how it should work). [expand-3.webm](https://github.com/user-attachments/assets/f20b0311-e92a-4e34-b640-1469b0d6fa16) How it works (Collapse): 1. Alt clicking any opened directory will collapse it and all its children, whether ignored or not. This is when you want to start from a fresh state. 2. When auto fold is enabled in settings, collapse action will also fold all subdirectories that it can fold. This is to bring it back to its fresh state as mentioned above. [collapse-1-2.webm](https://github.com/user-attachments/assets/74db6cee-0afa-406b-a9a2-7421083a2c2a) Future: - Using keybinding to expand/collapse all for selected entry - Handle expand/collapse all for folded entry Todos: - [x] Expand entries logic - [x] Handle remote worktree for expand - [x] Figure out scan complete status - [x] Move expansion logic to status update event - [x] Collapse entries logic - [x] Handle fold/unfold subdirs interaction - [x] Do not expand git ignored sub-dirs - [x] Tests - [x] Test Remote Release Notes: - Added Alt/Opt+Click functionality to expand or collapse a directory and all its contents. |
||
---|---|---|
.. | ||
k8s | ||
migrations | ||
migrations.sqlite | ||
migrations_llm | ||
seed | ||
src | ||
.env.toml | ||
Cargo.toml | ||
LICENSE-AGPL | ||
postgrest_app.conf | ||
postgrest_llm.conf | ||
README.md | ||
seed.default.json |
Zed Server
This crate is what we run at https://collab.zed.dev.
It contains our back-end logic for collaboration, to which we connect from the Zed client via a websocket after authenticating via https://zed.dev, which is a separate repo running on Vercel.
Local Development
Database setup
Before you can run the collab server locally, you'll need to set up a zed Postgres database. Follow the steps sequentially:
- Ensure you have postgres installed. If not, install with
brew install postgresql@15
. - Follow the steps on Brew's formula and verify your
$PATH
contains/opt/homebrew/opt/postgresql@15/bin
. - If you hadn't done it before, create the
postgres
user withcreateuser -s postgres
. - You are now ready to run the
bootstrap
script:
script/bootstrap
This script will set up the zed
Postgres database, and populate it with some users. It requires internet access, because it fetches some users from the GitHub API.
The script will create several admin users, who you'll sign in as by default when developing locally. The GitHub logins for the default users are specified in the seed.default.json
file.
To use a different set of admin users, create crates/collab/seed.json
.
{
"admins": ["yourgithubhere"],
"channels": ["zed"]
}
Testing collaborative features locally
In one terminal, run Zed's collaboration server and the livekit dev server:
foreman start
In a second terminal, run two or more instances of Zed.
script/zed-local -2
This script starts one to four instances of Zed, depending on the -2
, -3
or -4
flags. Each instance will be connected to the local collab
server, signed in as a different user from seed.json
or seed.default.json
.
Deployment
We run two instances of collab:
- Staging (https://staging-collab.zed.dev)
- Production (https://collab.zed.dev)
Both of these run on the Kubernetes cluster hosted in Digital Ocean.
Deployment is triggered by pushing to the collab-staging
(or collab-production
) tag in Github. The best way to do this is:
./script/deploy-collab staging
./script/deploy-collab production
You can tell what is currently deployed with ./script/what-is-deployed
.
Database Migrations
To create a new migration:
./script/create-migration <name>
Migrations are run automatically on service start, so run foreman start
again. The service will crash if the migrations fail.
When you create a new migration, you also need to update the SQLite schema that is used for testing.