Editor mode

Development reference · View source

Editor mode is Runyte as a simple editor for a configuration file or a system directory: one process with no workspace. Start it with runyte --editor [FILE or DIRECTORY], or with runed, which is the same program under another name and is always editor mode, whatever the mode setting says. runed rejects --ide, --mux, and the other options that would choose a mode or a workspace.

The installer puts runed beside runyte as a link, and the release archives include it (a copy, runed.exe, in the Windows zip). After cargo install, add it yourself, for example ln -s runyte ~/.cargo/bin/runed.

What editor mode keeps: editing, keys, your configuration and theme, syntax highlighting, undo, registers and the clipboard, safe saves, splits, help, :open with path completion, the directory tree, and the editable explorer with reviewed filesystem plans.

What it leaves out entirely: the .runyte/ directory, the diagnostic log (unless --log PATH is given), the recent-workspace list, persistent sessions, Git (no repository discovery, status-line branch, gutter marks, or Git views, even for a file inside a checkout), language servers, MCP, plugins, and integrated terminals. Their commands report not available in editor mode, and help and key hints grey them out. Pasting an image is refused too, because pasted images live in .runyte/. A session in editor mode stays in it; start runyte again for a workspace.

Search covers the directory in front of you. Space f, Space / f, the all-files Finder, and the project content searches (Space / s, Space / /, :fuzzy-grep) search below the active file’s or explorer’s directory instead of a project root, and their titles and prompts name that directory, as in search /etc/nginx: . Because that directory may be anywhere, these searches are contained:

They stay on the filesystem they start on, so mounts such as /proc below / are not entered.
They stop after reading 20,000 directory entries, hidden and ignored ones included, and say the result is limited.
They refuse to start at / or inside a virtual filesystem such as /proc, /sys, or /dev; open a narrower directory instead.

g f resolves relative paths beside the active file only.

The status line reads editor where it otherwise reads ide or ide+mux, labels the directory Directory: rather than Workspace:, and shows no Git information.

Running as root, Runyte runs only in editor mode: --ide, --mux, --wait, --serve, --init, and a configured ide or mux mode refuse and point to runed and sudoedit, because they would leave root-owned runtime state in a workspace another account owns.

Editing system files with sudo

Set SUDO_EDITOR to runed in your shell profile:
```
export SUDO_EDITOR=runed
```
Use the installed runed on PATH rather than a path into a build directory such as target/release, which breaks after a clean or during a rebuild.
Edit single files with sudoedit /etc/fstab. sudo copies the file to a temporary path, runs Runyte as you with your own configuration and theme, and copies the result back as root after you quit. Quitting without saving leaves the file unchanged. Runyte itself never runs as root.
Use sudo runed /etc only for what sudoedit cannot do: renaming, moving, or deleting files in system directories through the explorer. Runyte then runs as root, the filesystem plan says as root in its title, and deletions go to root’s trash (or the mount’s trash directory), not yours. Runyte finds its configuration through XDG_CONFIG_HOME and HOME, so whose configuration applies depends on the sudoers environment policy; with the common defaults it is root’s.