Zed companion (zed/) #5
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A Zed extension, Revue Companion, doing what the JetBrains plugin (
jetbrains/) does, as far as Zed lets an extension: the branch's pull request from Revue inside the editor, and the way back, with Revue opening a pull request in the Zed window that has its branch.Zed extensions are headless: they bring languages, language servers, themes, snippets, debuggers and MCP servers, and can run processes, but they can't add panels, menu items, Command Palette actions or gutter icons (the visual extension API is a proposal Zed says it won't get to soon). So the extension brings a small language server,
revue-lsp, for every language, and everything goes through what Zed already shows of one: code actions (cmd-.), diagnostics with hover, and project symbols (cmd-t). Being plain LSP,revue-lspcould serve Helix too.Features (as in the JetBrains plugin)
revue --pull-request <folder> --branch <branch>.LINK --file … --line …).--pending); a code action opens them in Revue. The pull request's changed lines the same way, off by default (Zed's own gutter shows changes against HEAD, not the pull request's base, and hints over every change are noisy).PR: <path>entries in project symbols (--branch-pull), each at its first change.lsp.revue.initialization_options.path(therevueexecutable; empty: PATH, then the install places the JetBrains plugin looks in), and whether to mark the changed lines.It talks to Revue only through the
revuecommand (Revue'sdocs/command-line.md, "What editors can ask"), and checksrevue --version'seditor <N>line before using it, as the JetBrains plugin does. No tokens enter the editor.The way back: Revue reaching a running Zed
Zed has no server or RPC socket an outside program can ask, but
revue-lspruns inside every Zed project, so it registers that project:<Revue's data folder>/companions/zed-<pid>.jsonwith{ "kind": "zed", "app": "Zed" | "Zed Preview", "pid", "port", "token", "version" }, listening on127.0.0.1on a free port. It removes the file on shutdown; Revue ignores a file whose pid isn't running or whose port refuses.GET /revue-projects, as the other companions answer: the project's worktrees, each repository's root, branch and remotes. Each request carries thetokenfrom the file.zed --existing <repository>/<file>:<line>for the window that has the branch, orzed <folder>for a new one; the language server can't focus a window itself.companionsmodule readszed-*files too, and the editor chooser (thatrichan/revue#68) treats Zed like any other companion. Revue'ssrc/apps.rs"open in Zed at a line" stays.Where it lives
zed/in this repository: the extension (extension.toml, Rust built to WASM withzed_extension_api) andrevue-lsp(a Rust crate). The extension downloads therevue-lspbinary for the platform from the Forgejo release (or uses one on PATH). Tests:revue-lspagainst a fakerevueprinting fixture JSON, driven over LSP. Arelease-zedworkflow started by hand (patch, minor, major) buildsrevue-lspfor macOS (arm64, x86_64), Linux (x86_64, arm64) and Windows, tagszed-vX.Y.Zand attaches them, likerelease-jetbrains. The extension is published by a pull request tozed-industries/extensions; to check whether it takes a submodule hosted on Forgejo or needs a GitHub mirror.Plan
revue-lspwith one code action, to check in a current Zed that code actions, hint diagnostics with hover and project symbols show for every language, and whether the server can be declared for all languages or users must add it per language.revue-lsp: findingrevue,--version, Open or Create Pull Request, Open File in Pull Request./revue-projects, then thatrichan/revue#68 choosing it and opening withzed --existing.docs/editors.mdZed section points to the extension, and Revue's stopgap is removed:editors/zed/(the Revue: Pull Request task and its keymap), made when Zed seemed unable to have an extension.Revue Companion for Zedto Zed companion (zed/)revuecommand, so Open in editor can reach them #80Plan steps 1 and 2 are in (merged in
da5cf1f):zed/with the extension,revue-lsp, andzed/PLAN.md.What the spike found (from Zed's source; not yet seen in a running Zed, see below):
extension.tomllists Zed's and the registry's 253 language names. Onerevue-lspruns per worktree whatever the language.inline_code_actions, on by default) shows wherever a server offers an action, and Zed doesn't sendtriggerKind, so the two Revue actions would put it on every line. To decide (see the plan).path = "zed": no GitHub mirror needed.revue-lsp: finds
revue(lsp.revue.initialization_options.path, PATH, the JetBrains plugin's places), gates oneditor N, and offers Revue: Open or Create Pull Request and Revue: Open File in Pull Request as code actions in any file. 28 tests over LSP against a small Rust fakerevue;task zed:test,zed:lint,zed:build.To check by hand (this machine's Rust has no
wasm32-wasip2):rustup target add wasm32-wasip2,task zed:build, pointlsp.revue.binary.pathatzed/target/release/revue-lsp, then zed: install dev extension onzed/(the plan's "Checking it in Zed").Next: step 3 (pending comments as hints, Go to Pull Request File in symbols). The way back waits on thatrichan/revue#80.
Steps 3 and 4 are in (merged in
d0e70ad):editor 9):revue-lsplistens on 127.0.0.1 with a fresh token, registers withrevue --companion zed(only when the client says it's Zed), answersGET /revue-projectsfor its workspace folders, and runs--companion-goneon shutdown. Revue then opens withzed --existing.editor 10): a code action on the selection or line that opens Revue's comment box on those lines (--write-comment), offered on the pull request's files.PR: <path>in project symbols (cmd-t);initialization_options.changes(off by default) marks the changed lines. The spike option is gone.44 tests over LSP pass. Still to check in Zed (
zed/PLAN.md→ "Checking it in Zed"); the first thing: that Zed sendsclientInfo.name"Zed" / "Zed Preview", or it never registers. Next: step 5 (CI,release-zed, publishing) and step 6 (docs).Steps 5 and 6 are in (merged in
ce33eba), so every step of the plan is built:.forgejo/workflows/zed.yml): lint, tests and the extension's WASM build on every push touchingzed/..forgejo/workflows/release-zed.yml, by hand): bumps the versions, regenerates the language list, buildsrevue-lspfor Linux (x86_64, arm64, musl) and Windows, tagszed-vX.Y.Zand attaches them. macOS builds need a Mac runner named in the repository variableMACOS_RUNNER; without one, tick without macOS.lsp.revue.initialization_options.actions_on_every_linebrings that back.zed/README.mdis the extension's page (install, settings, checking it, publishing tozed-industries/extensions), withLICENSE-MIT/LICENSE-APACHEcopies the registry wants.Revue's side (thatrichan/revue#80 and #81) is on Revue's main. Left: the first release, the pull request to Zed's extensions, and the "Checking it in Zed" list in a real Zed (this machine can't build the WASM).
Released as zed 0.1.0 for Linux and Windows on the Forgejo release (no macOS runner yet).
/revue-projectsnow lists repositories nested in a workspace folder. Not in Zed's extensions yet, so Revue's docs keep it under Coming soon. The ID decision, testing it in Zed, the registry pull request and a macOS build are in #9.