Opening files in an editor

Press e to open the highlighted file for editing — a file in the Changes tree, a file inside an expanded changelist, a saved patch in the Diffs view, or a .rej in the Rejects view.

The Changelists overview has no single file to open, so e says so instead.

With allowMouse on, double-clicking a file row opens it the same way.

Where in the file it opens

A file opens on its change rather than on line one.

Pressed from	Opens at
The Files panel	The first hunk of that file’s diff.
The Diff panel	The line under its cursor — move it with the arrow keys.
The side-by-side overlay	The file whose page is open, at the row on screen. The overlay closes, since it holds a snapshot.
The resolution overlay	The file being resolved, at the block on screen — for a reject, the file it was written for. The overlay closes, since it holds a snapshot.

When the Diff panel has focus it marks its current line with a highlight bar: that is the line e will land on. Jumping to a search match moves the cursor onto it, so n then e opens the file at the hit. So does double-clicking a line of the diff, which marks it and opens there in one go.

Directory rows work the same way through their combined diff: which file a hunk belongs to is written in the diff itself, so reading down a directory’s changes and pressing e opens whichever file you have reached.

The position is passed the way each editor expects it — +42 for the vi family, nano and emacs, --goto file:42 for VS Code, file:42 for Sublime Text and Helix. The desktop openers (open, xdg-open) take no position, so those open the file at the top.

Saved patches and .rej files are diffs already, so they open at the top too.

The editor setting

editor chooses what e runs. Change it in-app with S.

Value	What happens
native (default)	The environment decides — see below.
vim	Runs vim in this terminal, falling back to vi when that is the one installed.
nvim	Runs nvim in this terminal.
nano	Runs nano in this terminal.

A terminal editor takes the whole screen over until you quit it, and revision re-reads the working copy when it exits — so an edit shows up in the Changes tree and the diff immediately.

native usually opens the file beside revision instead, leaving the TUI on screen. Refresh with R when you are done.

How native resolves

1. A VS Code integrated terminal — the file opens as a tab in the window the terminal belongs to. Insiders, VSCodium and Cursor are recognised too.
2. $VISUAL or $EDITOR — run in this terminal, with any flags they carry (emacs -nw, code --wait).
3. The desktop’s default handler — open on macOS, xdg-open on Linux.

If none of those is available, e says so rather than guessing. Pick a terminal editor with S.

In VS Code, over a remote connection

When you open a folder with Remote-SSH (or a dev container, or WSL) and run revision in the integrated terminal, revision — like the terminal itself — is running on the server. Both editor modes are built for that.

vim / nvim / nano run on the server, in the terminal panel, editing the remote file in place. This also works over a plain ssh session, tmux, or anything else.

native uses the code command VS Code injects into the remote shell. That command does not run an editor on the server: it forwards the request over the existing connection to the VS Code window on your workstation, which opens the remote file in a tab — exactly as if you had clicked it in the Explorer. revision keeps running in the terminal panel below, and the file is saved back over the same connection.

One case to know about

If you open a local folder and then ssh to a server yourself from the integrated terminal, VS Code’s environment is not carried across — ssh does not forward it — so there is no window for native to talk to on the far side. It falls back to $EDITOR, and if that is unset the desktop opener fails on a headless server.

Set editor to vim, nvim or nano for those sessions.

e is in the Working copy section of the keybindings reference.